From antinvidia at gmail.com Sat Aug 1 06:59:32 2009 From: antinvidia at gmail.com (MQ) Date: Sat Aug 1 06:59:39 2009 Subject: [PATCH] type issue in kern_event.c In-Reply-To: <20090731221719.GS1292@hoeg.nl> References: <4A72B1DC.3040907@delphij.net> <86ocr062w9.fsf@ds4.des.no> <20090731221719.GS1292@hoeg.nl> Message-ID: 2009/8/1 Ed Schouten : > Hi Dag-Erling, > > * Dag-Erling Sm?rgrav wrote: >> Xin LI writes: >> > I think these should be fixed, and here is my proposed patch. >> >> 404 Patch Not Found > > Xin Li sent it to me, but I think he has forgotten to add the lists back > to Cc again. Here's the patch he sent to me earlier today. > > Index: kern_event.c > =================================================================== > --- kern_event.c (revision 195945) > +++ kern_event.c (working copy) > @@ -1106,7 +1106,7 @@ kqueue_expand(struct kqueue *kq, struct filterops > size = kq->kq_knlistsize; > while (size <= fd) > size += KQEXTENT; > - list = malloc(size * sizeof list, M_KQUEUE, mflag); > + list = malloc(size * sizeof *list, M_KQUEUE, mflag); > if (list == NULL) > return ENOMEM; > KQ_LOCK(kq); > @@ -1116,13 +1116,13 @@ kqueue_expand(struct kqueue *kq, struct filterops > } else { > if (kq->kq_knlist != NULL) { > bcopy(kq->kq_knlist, list, > - kq->kq_knlistsize * sizeof list); > + kq->kq_knlistsize * sizeof *list); > free(kq->kq_knlist, M_KQUEUE); > kq->kq_knlist = NULL; > } > bzero((caddr_t)list + > kq->kq_knlistsize * sizeof list, > - (size - kq->kq_knlistsize) * sizeof list); > + (size - kq->kq_knlistsize) * sizeof *list); > kq->kq_knlistsize = size; > kq->kq_knlist = list; > } > > -- > Ed Schouten > WWW: http://80386.nl/ > The sizof in the first argument of bzero should also be replaced. From bugmaster at FreeBSD.org Mon Aug 3 11:06:53 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 3 11:07:48 2009 Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org Message-ID: <200908031106.n73B6qUA088514@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From mav at FreeBSD.org Sat Aug 8 21:39:57 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Sat Aug 8 21:40:04 2009 Subject: Do we still need ATA disk CHS addressing? Message-ID: <4A7DF076.4070203@FreeBSD.org> While preparing wrapping ATA(4) low-level drivers code into CAM SIM, I would like to remove CHS addressing support to make code cleaner. CHS addressing is officially declared obsoleted and replaced by LBA. Since ATA/ATAPI-6 specification (October 2001) it is even no longer documented. Have anybody seen ATA drive without LBA support in last years? Any other objections against removing it? -- Alexander Motin From nyan at jp.FreeBSD.org Sun Aug 9 11:25:56 2009 From: nyan at jp.FreeBSD.org (Takahashi Yoshihiro) Date: Sun Aug 9 11:26:07 2009 Subject: Do we still need ATA disk CHS addressing? In-Reply-To: <4A7DF076.4070203@FreeBSD.org> References: <4A7DF076.4070203@FreeBSD.org> Message-ID: <20090809.202549.27838630.nyan@jp.FreeBSD.org> In article <4A7DF076.4070203@FreeBSD.org> Alexander Motin writes: > While preparing wrapping ATA(4) low-level drivers code into CAM SIM, I > would like to remove CHS addressing support to make code cleaner. CHS > addressing is officially declared obsoleted and replaced by LBA. Since > ATA/ATAPI-6 specification (October 2001) it is even no longer > documented. > > Have anybody seen ATA drive without LBA support in last years? > Any other objections against removing it? PC98 uses CHS addressing because the internal interface works for very old HDD only, so I hope it remains if possible. But if you need a lot of works for CHS support, I agree to remove it. --- TAKAHASHI Yoshihiro From ed at 80386.nl Sun Aug 9 13:47:26 2009 From: ed at 80386.nl (Ed Schouten) Date: Sun Aug 9 13:47:33 2009 Subject: Do we still need ATA disk CHS addressing? In-Reply-To: <20090809.202549.27838630.nyan@jp.FreeBSD.org> References: <4A7DF076.4070203@FreeBSD.org> <20090809.202549.27838630.nyan@jp.FreeBSD.org> Message-ID: <20090809134724.GX1292@hoeg.nl> * Takahashi Yoshihiro wrote: > In article <4A7DF076.4070203@FreeBSD.org> > Alexander Motin writes: > > > While preparing wrapping ATA(4) low-level drivers code into CAM SIM, I > > would like to remove CHS addressing support to make code cleaner. CHS > > addressing is officially declared obsoleted and replaced by LBA. Since > > ATA/ATAPI-6 specification (October 2001) it is even no longer > > documented. > > > > Have anybody seen ATA drive without LBA support in last years? > > Any other objections against removing it? > > PC98 uses CHS addressing because the internal interface works for very > old HDD only, so I hope it remains if possible. But if you need a lot > of works for CHS support, I agree to remove it. Wouldn't it be possible to keep the old ATA code in the tree for users who want to use stuff like this? -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090809/ce8390fc/attachment.pgp From mav at FreeBSD.org Sun Aug 9 14:15:52 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Sun Aug 9 14:16:05 2009 Subject: Do we still need ATA disk CHS addressing? In-Reply-To: <20090809134724.GX1292@hoeg.nl> References: <4A7DF076.4070203@FreeBSD.org> <20090809.202549.27838630.nyan@jp.FreeBSD.org> <20090809134724.GX1292@hoeg.nl> Message-ID: <4A7ED9DF.1080007@FreeBSD.org> Ed Schouten wrote: > * Takahashi Yoshihiro wrote: >> In article <4A7DF076.4070203@FreeBSD.org> >> Alexander Motin writes: >>> While preparing wrapping ATA(4) low-level drivers code into CAM SIM, I >>> would like to remove CHS addressing support to make code cleaner. CHS >>> addressing is officially declared obsoleted and replaced by LBA. Since >>> ATA/ATAPI-6 specification (October 2001) it is even no longer >>> documented. >>> >>> Have anybody seen ATA drive without LBA support in last years? >>> Any other objections against removing it? >> PC98 uses CHS addressing because the internal interface works for very >> old HDD only, so I hope it remains if possible. But if you need a lot >> of works for CHS support, I agree to remove it. > > Wouldn't it be possible to keep the old ATA code in the tree for users > who want to use stuff like this? I am going to make it switchable via kernel option, until new code completely settle. It should be possible to keep CHS support in this legacy mode. -- Alexander Motin From jhs at berklix.com Mon Aug 10 09:32:45 2009 From: jhs at berklix.com (Julian H. Stacey) Date: Mon Aug 10 09:33:04 2009 Subject: Do we still need ATA disk CHS addressing? In-Reply-To: Your message "Sun, 09 Aug 2009 00:39:02 +0300." <4A7DF076.4070203@FreeBSD.org> Message-ID: <200908100904.n7A94BAB044505@fire.js.berklix.net> > Have anybody seen ATA drive without LBA support in last years? Yes > Any other objections against removing it? Yes object sorry. Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail ASCII plain text not HTML & Base64. http://asciiribbon.org Virused Microsoft PCs cause spam. http://berklix.com/free/ From mav at FreeBSD.org Mon Aug 10 09:43:03 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Mon Aug 10 09:43:15 2009 Subject: Do we still need ATA disk CHS addressing? In-Reply-To: <200908100904.n7A94BAB044505@fire.js.berklix.net> References: <200908100904.n7A94BAB044505@fire.js.berklix.net> Message-ID: <4A7FEBA2.5090106@FreeBSD.org> Julian H. Stacey wrote: >> Have anybody seen ATA drive without LBA support in last years? > Yes What it is? Some ancient HDD or flash card? -- Alexander Motin From bugmaster at FreeBSD.org Mon Aug 10 11:06:51 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 10 11:07:27 2009 Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org Message-ID: <200908101106.n7AB6ovJ025061@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From jhs at berklix.com Mon Aug 10 16:38:33 2009 From: jhs at berklix.com (Julian H. Stacey) Date: Mon Aug 10 16:38:45 2009 Subject: Do we still need ATA disk CHS addressing? In-Reply-To: Your message "Mon, 10 Aug 2009 12:42:58 +0300." <4A7FEBA2.5090106@FreeBSD.org> Message-ID: <200908101640.n7AGeYH0054650@fire.js.berklix.net> Hi Alexander, > Julian H. Stacey wrote: > >> Have anybody seen ATA drive without LBA support in last years? > > Yes > What it is? Some ancient HDD or flash card? Sorry my first reply was short, a holding reply, ( A server died, & 2nd reserve needed time, still does ) I run 20+ assorted hosts from 4.11 to 7.2 Uni & Dual proc, i386 (real 386!) to 686 & amd64, so I guess I'm A) Pretty vulnerable to legacy scare. B) A litmus tesst for a wider community of others, some with older kit, not on lists or with bleeding edge latest hardware, but will get hit when stuff eg HCS gets declared legacy=dumped. (hardware@ & arch@ are more likely mostly high enders, lower percentage of legacy hardware users I guess) If I have to pull the lid on 20/25 hosts, to check disk sticky labels, I will if I must, but could you please reccomend people syntax to run on 4 5 6 7 RELEASES to check if a host is susceptible ? (Yes I know 4 is declares dead, but I still have lots of hosts with it & I suspect quite a lot of others do, be nice to know if any of those boxes are doomed to only upgarde to 7 not 8 ) BTW My configs & dmesg extract: http://berklix.com/~jhs/src/bsd/fixes/FreeBSD/src/jhs/sys/i386/conf/HOLZ The genuine 386 host uses config name MINI. The config name SCAN represents a class of scanners with embedded FreeBSD inside that a bunch of people have http://berklix.com/scanjet/ I will turn on more verbose boot to increase http://berklix.com/scanjet/dmesg/4.11/ from its too minimal current ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail ASCII plain text not HTML & Base64. http://asciiribbon.org Virused Microsoft PCs cause spam. http://berklix.com/free/ From mav at FreeBSD.org Mon Aug 10 17:44:12 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Mon Aug 10 17:44:24 2009 Subject: Do we still need ATA disk CHS addressing? In-Reply-To: <200908101640.n7AGeYH0054650@fire.js.berklix.net> References: <200908101640.n7AGeYH0054650@fire.js.berklix.net> Message-ID: <4A805C2E.8020300@FreeBSD.org> Julian H. Stacey wrote: >> Julian H. Stacey wrote: >>>> Have anybody seen ATA drive without LBA support in last years? >>> Yes >> What it is? Some ancient HDD or flash card? > > I run 20+ assorted hosts from 4.11 to 7.2 Uni & Dual proc, i386 (real 386!) > to 686 & amd64, so I guess I'm > A) Pretty vulnerable to legacy scare. > B) A litmus tesst for a wider community of others, some with older kit, > not on lists or with bleeding edge latest hardware, but will > get hit when stuff eg HCS gets declared legacy=dumped. > (hardware@ & arch@ are more likely mostly high enders, > lower percentage of legacy hardware users I guess) Are you administering computer hardware museum? ;) I have tested all drives I have and found none requiring CHS support. Even most ancient 850MB HDD and 16MB CompactFlash card I have support LBA. I have doubts that something even older that this is still working in production and require system there to be upgraded to 8.x. > If I have to pull the lid on 20/25 hosts, to check disk sticky > labels, I will if I must, but could you please reccomend people > syntax to run on 4 5 6 7 RELEASES to check if a host is susceptible ? > (Yes I know 4 is declares dead, but I still have lots of > hosts with it & I suspect quite a lot of others do, > be nice to know if any of those boxes are doomed to only > upgarde to 7 not 8 ) `atacontrol cap adX` can show you if LBA is supported. -- Alexander Motin From des at des.no Mon Aug 10 18:38:18 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Aug 10 18:38:25 2009 Subject: Do we still need ATA disk CHS addressing? In-Reply-To: <200908101640.n7AGeYH0054650@fire.js.berklix.net> (Julian H. Stacey's message of "Mon, 10 Aug 2009 18:40:34 +0200") References: <200908101640.n7AGeYH0054650@fire.js.berklix.net> Message-ID: <86eirjbjl3.fsf@ds4.des.no> "Julian H. Stacey" writes: > Alexander Motin writes: > > Have anybody seen ATA drive without LBA support in last years? > Yes Have you really, or did you just assume that "old" means "no LBA"? > I run 20+ assorted hosts from 4.11 to 7.2 Uni & Dual proc, i386 (real 386!) > to 686 & amd64 so I guess I'm > A) Pretty vulnerable to legacy scare. > B) A litmus tesst for a wider community of others, some with older kit, > not on lists or with bleeding edge latest hardware, but will > get hit when stuff eg HCS gets declared legacy=dumped. Do you seriously intend to run FreeBSD 9 on kit that is too old to support LBA? We're talking early nineties here. CHS doesn't scale past 504 MB, so any ATA disk larger than that must peforce support LBA. I bought my first 1 GB drive (Connor CFP1080) in 1995. DES -- Dag-Erling Sm?rgrav - des@des.no From jhs at berklix.com Mon Aug 10 18:52:44 2009 From: jhs at berklix.com (Julian H. Stacey) Date: Mon Aug 10 18:52:50 2009 Subject: Do we still need ATA disk CHS addressing? In-Reply-To: Your message "Mon, 10 Aug 2009 20:38:16 +0200." <86eirjbjl3.fsf@ds4.des.no> Message-ID: <200908101854.n7AIseFv056967@fire.js.berklix.net> > From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= wrote: > "Julian H. Stacey" writes: > > Alexander Motin writes: > > > Have anybody seen ATA drive without LBA support in last years? > > Yes > > Have you really, or did you just assume that "old" means "no LBA"? Yes, I just assumed. > CHS doesn't scale past > 504 MB, so any ATA disk larger than that must peforce support LBA. Ah! If so, then no problem here, Thanks Dag-Erling :-) Alexander Motin wrote: > `atacontrol cap adX` can show you if LBA is supported. Thanks Alexander, I will check that tomorrow on every host I have. Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail ASCII plain text not HTML & Base64. http://asciiribbon.org Virused Microsoft PCs cause spam. http://berklix.com/free/ From imp at bsdimp.com Mon Aug 10 18:57:27 2009 From: imp at bsdimp.com (Warner Losh) Date: Mon Aug 10 18:57:39 2009 Subject: Do we still need ATA disk CHS addressing? In-Reply-To: <86eirjbjl3.fsf@ds4.des.no> References: <200908101640.n7AGeYH0054650@fire.js.berklix.net> <86eirjbjl3.fsf@ds4.des.no> Message-ID: <20090810.125403.74653324.imp@bsdimp.com> From: Dag-Erling Sm?rgrav Subject: Re: Do we still need ATA disk CHS addressing? Date: Mon, 10 Aug 2009 20:38:16 +0200 > "Julian H. Stacey" writes: > > Alexander Motin writes: > > > Have anybody seen ATA drive without LBA support in last years? > > Yes > > Have you really, or did you just assume that "old" means "no LBA"? > > > I run 20+ assorted hosts from 4.11 to 7.2 Uni & Dual proc, i386 (real 386!) > > to 686 & amd64 so I guess I'm > > A) Pretty vulnerable to legacy scare. > > B) A litmus tesst for a wider community of others, some with older kit, > > not on lists or with bleeding edge latest hardware, but will > > get hit when stuff eg HCS gets declared legacy=dumped. > > Do you seriously intend to run FreeBSD 9 on kit that is too old to > support LBA? We're talking early nineties here. CHS doesn't scale past > 504 MB, so any ATA disk larger than that must peforce support LBA. I > bought my first 1 GB drive (Connor CFP1080) in 1995. Is that also true in the pc98 realm? There's a number of weird combinations there which use CHS addressing, but that's kinda forced onto it by weird pc98 disk label format. I don't know if this is required, and older stuff just won't work or not, but I do know that there be dragons there. I know, at the very least, that the system requires that the CHS geometry reported by the drive be faithfully preserved. It is something we should ask nyan-san about at the very least... As for the 'are you seriously going to run FreeBSD 9 on them' argument, there's a rather large number of systems that people said would be too slow to run FreeBSD 7 or 8, yet they are running them better than anticipated. They said that about many of the same systems that Julian is running today. My question, and maybe I missed this earlier in the thread, is what's the benefit to removing this support? How much code is saved? Having said all that, I think it is OK, but I'd definitely poll the pc98 guys first... Just to make sure they don't need it and re-fork the ata driver to get it :) Warner From ertr1013 at student.uu.se Mon Aug 10 19:19:11 2009 From: ertr1013 at student.uu.se (Erik Trulsson) Date: Mon Aug 10 19:19:17 2009 Subject: Do we still need ATA disk CHS addressing? In-Reply-To: <86eirjbjl3.fsf@ds4.des.no> References: <200908101640.n7AGeYH0054650@fire.js.berklix.net> <86eirjbjl3.fsf@ds4.des.no> Message-ID: <20090810190258.GA25641@owl.midgard.homeip.net> On Mon, Aug 10, 2009 at 08:38:16PM +0200, Dag-Erling Sm?rgrav wrote: > "Julian H. Stacey" writes: > > Alexander Motin writes: > > > Have anybody seen ATA drive without LBA support in last years? > > Yes > > Have you really, or did you just assume that "old" means "no LBA"? > > > I run 20+ assorted hosts from 4.11 to 7.2 Uni & Dual proc, i386 (real 386!) > > to 686 & amd64 so I guess I'm > > A) Pretty vulnerable to legacy scare. > > B) A litmus tesst for a wider community of others, some with older kit, > > not on lists or with bleeding edge latest hardware, but will > > get hit when stuff eg HCS gets declared legacy=dumped. > > Do you seriously intend to run FreeBSD 9 on kit that is too old to > support LBA? We're talking early nineties here. CHS doesn't scale past > 504 MB, so any ATA disk larger than that must peforce support LBA. I > bought my first 1 GB drive (Connor CFP1080) in 1995. Actually I believe even the very first version of the ATA standard (long before support for LBA or any other modern features was added) could handle larger disks than 504MiB. I think the original limit of ATA was 2.1 GB. The 504MiB limit was actually the intersection between the limits of the PC BIOS and the limits of the ATA standard. (ATA and the BIOS had different number of bits used to indicate each of cylinder, head and sector. When you took the lower number of bits for each you ended up with the 504MiB limit.) -- Erik Trulsson ertr1013@student.uu.se From mav at FreeBSD.org Mon Aug 10 19:59:27 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Mon Aug 10 19:59:33 2009 Subject: Do we still need ATA disk CHS addressing? In-Reply-To: <20090810.125403.74653324.imp@bsdimp.com> References: <200908101640.n7AGeYH0054650@fire.js.berklix.net> <86eirjbjl3.fsf@ds4.des.no> <20090810.125403.74653324.imp@bsdimp.com> Message-ID: <4A807BDD.6040709@FreeBSD.org> Warner Losh wrote: > My question, and maybe I missed this earlier in the thread, is what's > the benefit to removing this support? How much code is saved? It is not about code size, but about code structurization. ATA(4) has too much cross-level relations, making it cryptic. I am trying to unroll some of them to simplify code. > Having said all that, I think it is OK, but I'd definitely poll the > pc98 guys first... Just to make sure they don't need it and re-fork > the ata driver to get it :) GEOM has no terms of cylinders/heads/sectors, in fact it works only with LBA. CHS translation is only needed for drives, that have no native LBA support. It is not about disk partitioning or label format. It is just a method to linearize nonlinear address space of ancient drives. For last 10 years, since drives lost their classic geometry, drives are doing this translation on firmware level. -- Alexander Motin From imp at bsdimp.com Mon Aug 10 22:27:20 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Mon Aug 10 22:27:34 2009 Subject: Do we still need ATA disk CHS addressing? In-Reply-To: <4A807BDD.6040709@FreeBSD.org> References: <86eirjbjl3.fsf@ds4.des.no> <20090810.125403.74653324.imp@bsdimp.com> <4A807BDD.6040709@FreeBSD.org> Message-ID: <20090810.162424.846948847.imp@bsdimp.com> In message: <4A807BDD.6040709@FreeBSD.org> Alexander Motin writes: : Warner Losh wrote: : > My question, and maybe I missed this earlier in the thread, is what's : > the benefit to removing this support? How much code is saved? : : It is not about code size, but about code structurization. ATA(4) has : too much cross-level relations, making it cryptic. I am trying to unroll : some of them to simplify code. Can you explain a bit more here... How pervasive is it, etc... I'm not saying this is a bad change, but I think people wishing to remove stuff should at least have a good result that's expected... : > Having said all that, I think it is OK, but I'd definitely poll the : > pc98 guys first... Just to make sure they don't need it and re-fork : > the ata driver to get it :) : : GEOM has no terms of cylinders/heads/sectors, in fact it works only with : LBA. CHS translation is only needed for drives, that have no native LBA : support. It is not about disk partitioning or label format. It is just a : method to linearize nonlinear address space of ancient drives. For last : 10 years, since drives lost their classic geometry, drives are doing : this translation on firmware level. GEOM does have terms of CHS when it reports the classic geometry of the device. That can't be lost, or pc98 partitioning breaks. And the geometry reported must be massaged too, but that's a different issue. The disk requests can be LBA, since the driver is responsible for changing that anyway... I don't think that there's any supported pc98 hardware that would break, but I'm not 100% sure... There's also some oddities at the lowest levels for pc98 controllers, but I don't think this change would affect that. However, like I said, ask the pc98 guys for sure. I've cc'd nyan@, since he can answer the question: "What breaks in pc98 if we lose support for CHS-based disk I/O?" Warner From mav at FreeBSD.org Tue Aug 11 07:35:14 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Tue Aug 11 07:35:21 2009 Subject: Do we still need ATA disk CHS addressing? In-Reply-To: <20090810.162424.846948847.imp@bsdimp.com> References: <86eirjbjl3.fsf@ds4.des.no> <20090810.125403.74653324.imp@bsdimp.com> <4A807BDD.6040709@FreeBSD.org> <20090810.162424.846948847.imp@bsdimp.com> Message-ID: <4A811F2B.7050402@FreeBSD.org> M. Warner Losh wrote: > In message: <4A807BDD.6040709@FreeBSD.org> > Alexander Motin writes: > : Warner Losh wrote: > : > My question, and maybe I missed this earlier in the thread, is what's > : > the benefit to removing this support? How much code is saved? > : > : It is not about code size, but about code structurization. ATA(4) has > : too much cross-level relations, making it cryptic. I am trying to unroll > : some of them to simplify code. > > Can you explain a bit more here... How pervasive is it, etc... I'm > not saying this is a bad change, but I think people wishing to remove > stuff should at least have a good result that's expected... Do you really wish to touch it? Fine... CHS translation is now done on ATA controller drivers level. To work properly it needs data from drive IDENTIFY structure fetched from drive and stored on higher level. To wrap legacy ATA into CAM SIM I need to break that dependency either with dropping this functionality or reimplementing it on higher level. I would prefer first. > : > Having said all that, I think it is OK, but I'd definitely poll the > : > pc98 guys first... Just to make sure they don't need it and re-fork > : > the ata driver to get it :) > : > : GEOM has no terms of cylinders/heads/sectors, in fact it works only with > : LBA. CHS translation is only needed for drives, that have no native LBA > : support. It is not about disk partitioning or label format. It is just a > : method to linearize nonlinear address space of ancient drives. For last > : 10 years, since drives lost their classic geometry, drives are doing > : this translation on firmware level. > > GEOM does have terms of CHS when it reports the classic geometry of > the device. That can't be lost, or pc98 partitioning breaks. And the > geometry reported must be massaged too, but that's a different issue. That's completely different, and I am not going to touch it. > The disk requests can be LBA, since the driver is responsible for > changing that anyway... I don't think that there's any supported > pc98 hardware that would break, but I'm not 100% sure... > > There's also some oddities at the lowest levels for pc98 controllers, > but I don't think this change would affect that. However, like I > said, ask the pc98 guys for sure. As you could see reading above thread, I have agreed keep it in legacy ATA mode. But it looks pointless to support it in new development. -- Alexander Motin From nyan at jp.FreeBSD.org Tue Aug 11 10:56:12 2009 From: nyan at jp.FreeBSD.org (Takahashi Yoshihiro) Date: Tue Aug 11 10:56:25 2009 Subject: Do we still need ATA disk CHS addressing? In-Reply-To: <20090810.162424.846948847.imp@bsdimp.com> References: <20090810.125403.74653324.imp@bsdimp.com> <4A807BDD.6040709@FreeBSD.org> <20090810.162424.846948847.imp@bsdimp.com> Message-ID: <20090811.195559.61406403.nyan@jp.FreeBSD.org> In article <20090810.162424.846948847.imp@bsdimp.com> "M. Warner Losh" writes: > There's also some oddities at the lowest levels for pc98 controllers, > but I don't think this change would affect that. However, like I > said, ask the pc98 guys for sure. > > I've cc'd nyan@, since he can answer the question: "What breaks in > pc98 if we lose support for CHS-based disk I/O?" The following document in Japanese says: "PC-98 usually use CHS addressing. PC-98 does not use LBA addressing." http://www.webtech.co.jp/company/doc/undocumented_mem/io_ide.txt But I could use 400MB HDD with LBA addressing on my pc98, so it seems that my pc98 supports LBA addressing at least. I don't know older pc98 supports it or not. --- TAKAHASHI Yoshihiro From peterjeremy at optushome.com.au Sat Aug 15 04:43:03 2009 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Sat Aug 15 04:43:10 2009 Subject: C99 Complex Math Functions Message-ID: <20090815015947.GA4682@server.vk2pj.dyndns.org> Hi David, I've recently had a requirement for the C99 complex math functions. I know you have been doing some work on implementing functions in complex.h and wonder what (if any) plans you have for implementing the rest of the C99 functions. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090815/146d72ad/attachment.pgp From bugmaster at FreeBSD.org Mon Aug 17 11:06:50 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 17 11:07:18 2009 Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org Message-ID: <200908171106.n7HB6nv6075704@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From das at FreeBSD.ORG Mon Aug 17 20:28:30 2009 From: das at FreeBSD.ORG (David Schultz) Date: Mon Aug 17 20:28:36 2009 Subject: C99 Complex Math Functions In-Reply-To: <20090815015947.GA4682@server.vk2pj.dyndns.org> References: <20090815015947.GA4682@server.vk2pj.dyndns.org> Message-ID: <20090817201319.GA22437@zim.MIT.EDU> On Sat, Aug 15, 2009, Peter Jeremy wrote: > Hi David, > > I've recently had a requirement for the C99 complex math functions. > I know you have been doing some work on implementing functions in > complex.h and wonder what (if any) plans you have for implementing > the rest of the C99 functions. Which ones do you need? They are on my todo list, but they're not a priority, and I'm swamped right now, so don't hold your breath! Steve Kargle and Bruce Evans also have some interest in this. Many of the functions can be fudged with some simple formulas that you can look up. The simple formulas work great in most cases, but often fail near asymptotes and for special cases (infinity, NaN, underflow, etc.) From avg at freebsd.org Tue Aug 18 10:54:16 2009 From: avg at freebsd.org (Andriy Gapon) Date: Tue Aug 18 10:54:23 2009 Subject: on architecture of dumping Message-ID: <4A8A85ED.4090404@freebsd.org> I think that the following is quite obvious, but it needs to be said anyway. I think that we should switch from current approach of hierarchically configuring dumper to having a hierarchy of dumpers. Right now only disks provide dumping routines and the layers above disks can only set offset and size of dump area. This results in the following limitations: 1. dump can be made only to contiguous area of a disk 2. dump can be made only to a single disk Having a hierarchy of dumpers is a need that arises from having a GEOM hierarchy. I think that each compliant GEOM provider could expose a dump method for writing out a blob of data to certain offset within the provider. Such a dump routine would dispatch data to dump methods of underlying provider(s) according to provider's logic. Disk providers would have almost the same dump routines as they do now (they are actually in disk drivers). This would allow, for example, mirrored dumping to gmirror devices. And this would pave a way for porting dumping to a zvol from OpenSolaris. Please comment. Thank you. -- Andriy Gapon From phk at phk.freebsd.dk Tue Aug 18 11:16:47 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue Aug 18 11:16:53 2009 Subject: on architecture of dumping In-Reply-To: Your message of "Tue, 18 Aug 2009 13:43:57 +0300." <4A8A85ED.4090404@freebsd.org> Message-ID: <90048.1250593186@critter.freebsd.dk> In message <4A8A85ED.4090404@freebsd.org>, Andriy Gapon writes: > >I think that the following is quite obvious, but it needs to be said anyway. > >I think that we should switch from current approach of hierarchically >configuring dumper to having a hierarchy of dumpers. I think this is utterly wolly thinking. The amount of complexity this will impose is staggering, and the potential benefit is no where close to justifying it. Add a cheap ATA disk for your dumps or make an USB stick work for dumps and use that. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From avg at freebsd.org Tue Aug 18 11:55:09 2009 From: avg at freebsd.org (Andriy Gapon) Date: Tue Aug 18 11:55:15 2009 Subject: on architecture of dumping In-Reply-To: <90048.1250593186@critter.freebsd.dk> References: <90048.1250593186@critter.freebsd.dk> Message-ID: <4A8A9699.1020808@freebsd.org> on 18/08/2009 13:59 Poul-Henning Kamp said the following: > In message <4A8A85ED.4090404@freebsd.org>, Andriy Gapon writes: >> I think that the following is quite obvious, but it needs to be said anyway. >> >> I think that we should switch from current approach of hierarchically >> configuring dumper to having a hierarchy of dumpers. > > I think this is utterly wolly thinking. 'wolly'? Please improve my English. > The amount of complexity this will impose is staggering, and the potential > benefit is no where close to justifying it. I can't see the staggering complexity in the proposal, could you please expand? Example of what I had in mind (pseudo-code): static int gmirror_dump(this, void *data, off_t offset, size_t size) { LIST_FOREACH(pp, ...) { DUMP(pp, data, offset, size); } } > Add a cheap ATA disk for your dumps or make an USB stick work for dumps > and use that. Say, I do want mirrored dumps and/or I do want encrypted dumps - wouldn't it be logical to re-use GEOM capabilities here. -- Andriy Gapon From phk at phk.freebsd.dk Tue Aug 18 11:57:20 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue Aug 18 11:57:26 2009 Subject: on architecture of dumping In-Reply-To: Your message of "Tue, 18 Aug 2009 14:55:05 +0300." <4A8A9699.1020808@freebsd.org> Message-ID: <28518.1250596643@critter.freebsd.dk> In message <4A8A9699.1020808@freebsd.org>, Andriy Gapon writes: >>> I think that we should switch from current approach of hierarchically >>> configuring dumper to having a hierarchy of dumpers. >> >> I think this is utterly wolly thinking. > >'wolly'? Please improve my English. Wolly as in "unclear". >> The amount of complexity this will impose is staggering, and the potential >> benefit is no where close to justifying it. > >I can't see the staggering complexity in the proposal, could you please expand? >Example of what I had in mind (pseudo-code): That may be the difference between you and me, I do see the complexity. I suggest you try to implement it, it is probably just as fast as me trying to convince you this is not simple. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From gary.jennejohn at freenet.de Tue Aug 18 15:37:13 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Tue Aug 18 15:37:19 2009 Subject: on architecture of dumping In-Reply-To: <28518.1250596643@critter.freebsd.dk> References: <4A8A9699.1020808@freebsd.org> <28518.1250596643@critter.freebsd.dk> Message-ID: <20090818173710.1082a7af@ernst.jennejohn.org> On Tue, 18 Aug 2009 11:57:23 +0000 "Poul-Henning Kamp" wrote: > In message <4A8A9699.1020808@freebsd.org>, Andriy Gapon writes: > > >>> I think that we should switch from current approach of hierarchically > >>> configuring dumper to having a hierarchy of dumpers. > >> > >> I think this is utterly wolly thinking. > > > >'wolly'? Please improve my English. > > Wolly as in "unclear". > phk means wooly. Here the applicable definition found with dict: wooly 2: confused and vague; used especially of thinking; "muddleheaded ideas"; "your addled little brain"; "woolly thinking"; "woolly-headed ideas" [syn: {addled}, {befuddled}, {muddled}, {muzzy}, {woolly}, {woolly-headed}, {wooly-minded}] --- Gary Jennejohn From des at des.no Wed Aug 19 11:15:11 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Wed Aug 19 11:15:17 2009 Subject: on architecture of dumping In-Reply-To: <20090818173710.1082a7af@ernst.jennejohn.org> (Gary Jennejohn's message of "Tue, 18 Aug 2009 17:37:10 +0200") References: <4A8A9699.1020808@freebsd.org> <28518.1250596643@critter.freebsd.dk> <20090818173710.1082a7af@ernst.jennejohn.org> Message-ID: <863a7ot5qa.fsf@ds4.des.no> Gary Jennejohn writes: > "Poul-Henning Kamp" writes: > > Wolly as in "unclear". ===== > phk means wooly. Here the applicable definition found with dict: ===== > wooly > 2: confused and vague; used especially of thinking; > "muddleheaded ideas"; "your addled little brain"; "woolly ====== :) DES -- Dag-Erling Sm?rgrav - des@des.no From gary.jennejohn at freenet.de Wed Aug 19 13:01:34 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Wed Aug 19 13:01:45 2009 Subject: on architecture of dumping In-Reply-To: <863a7ot5qa.fsf@ds4.des.no> References: <4A8A9699.1020808@freebsd.org> <28518.1250596643@critter.freebsd.dk> <20090818173710.1082a7af@ernst.jennejohn.org> <863a7ot5qa.fsf@ds4.des.no> Message-ID: <20090819150131.5d6a77b8@ernst.jennejohn.org> On Wed, 19 Aug 2009 13:15:09 +0200 Dag-Erling Sm__rgrav wrote: > Gary Jennejohn writes: > > "Poul-Henning Kamp" writes: > > > Wolly as in "unclear". > ===== > > phk means wooly. Here the applicable definition found with dict: > ===== > > wooly > > 2: confused and vague; used especially of thinking; > > "muddleheaded ideas"; "your addled little brain"; "woolly > ====== > > :) > That's English for you. If it can be confusing, then it is :) --- Gary Jennejohn From sgk at troutmask.apl.washington.edu Thu Aug 20 23:04:01 2009 From: sgk at troutmask.apl.washington.edu (Steve Kargl) Date: Thu Aug 20 23:04:07 2009 Subject: C99 Complex Math Functions In-Reply-To: <20090817201319.GA22437@zim.MIT.EDU> References: <20090815015947.GA4682@server.vk2pj.dyndns.org> <20090817201319.GA22437@zim.MIT.EDU> Message-ID: <20090820230400.GA61066@troutmask.apl.washington.edu> On Mon, Aug 17, 2009 at 04:13:19PM -0400, David Schultz wrote: > On Sat, Aug 15, 2009, Peter Jeremy wrote: > > Hi David, > > > > I've recently had a requirement for the C99 complex math functions. > > I know you have been doing some work on implementing functions in > > complex.h and wonder what (if any) plans you have for implementing > > the rest of the C99 functions. > > Which ones do you need? > > They are on my todo list, but they're not a priority, and I'm > swamped right now, so don't hold your breath! Steve Kargle and > Bruce Evans also have some interest in this. > > Many of the functions can be fudged with some simple formulas that > you can look up. The simple formulas work great in most cases, > but often fail near asymptotes and for special cases (infinity, > NaN, underflow, etc.) In a private response to Peter, I directed him to NetBSD. NetBSD contains some/most(?)/all(?) of the simple formula implementations. I sent Peter the guts of ccosh as implemented by NetBSD (the simple formula) and the current version of ccosh that Bruce and I had written. The netbsd version is 15 lines (excluding the license). The bde+me version is 91 lines (excluding license and initial comment). To be fair, a large portion of those 91 lines are comments of the form /* * cosh(+-Inf + I NaN) = +Inf + I d(NaN). * * cosh(+-Inf +- I Inf) = +Inf + I dNaN. * The sign of Inf in the result is unspecified. Choice = always +. * Raise the invalid floating-point exception. * * cosh(+-Inf + I y) = +Inf cos(y) +- I Inf sin(y) */ To be more fair, most of the comments with the above form are due to Bruce as well as the details of the implementation. PS: yes, I'll get around to completing the commit bit stuff one of these days. But, for now, I need to return to a report that is 6 weeks late and 2 proposals. -- Steve From peterjeremy at optushome.com.au Fri Aug 21 09:38:53 2009 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Fri Aug 21 09:39:00 2009 Subject: C99 Complex Math Functions In-Reply-To: <20090820230400.GA61066@troutmask.apl.washington.edu> References: <20090815015947.GA4682@server.vk2pj.dyndns.org> <20090817201319.GA22437@zim.MIT.EDU> <20090820230400.GA61066@troutmask.apl.washington.edu> Message-ID: <20090821093849.GA33774@server.vk2pj.dyndns.org> On 2009-Aug-20 16:04:00 -0700, Steve Kargl wrote: >On Mon, Aug 17, 2009 at 04:13:19PM -0400, David Schultz wrote: >> On Sat, Aug 15, 2009, Peter Jeremy wrote: >> > I've recently had a requirement for the C99 complex math functions. >> > I know you have been doing some work on implementing functions in >> > complex.h and wonder what (if any) plans you have for implementing >> > the rest of the C99 functions. >> >> Which ones do you need? cacos, cacosh, casin, casinh, catan, catanh, ccos, ccosh, cexp, clog, cpow, csin, csinh, ctan, ctanh :-) >> Many of the functions can be fudged with some simple formulas that >> you can look up. I have all the simple formulae. >> The simple formulas work great in most cases, >> but often fail near asymptotes and for special cases (infinity, >> NaN, underflow, etc.) And simplistic implementations can lose significant amounts of precision as well. >In a private response to Peter, I directed him to NetBSD. Thanks for that. I've also discovered that math/gsl also implements the required functions (though with non-standard names and argument types). Since I already have gsl available, I might use it instead. (As a warning for anyone else interested in math/gsl - it's complex functions are implemented very simplisticly - no better than NetBSD). -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090821/5b38dbf7/attachment.pgp From brde at optusnet.com.au Fri Aug 21 09:45:18 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Fri Aug 21 09:45:25 2009 Subject: C99 Complex Math Functions In-Reply-To: <20090820230400.GA61066@troutmask.apl.washington.edu> References: <20090815015947.GA4682@server.vk2pj.dyndns.org> <20090817201319.GA22437@zim.MIT.EDU> <20090820230400.GA61066@troutmask.apl.washington.edu> Message-ID: <20090821190006.E36897@delplex.bde.org> On Thu, 20 Aug 2009, Steve Kargl wrote: > On Mon, Aug 17, 2009 at 04:13:19PM -0400, David Schultz wrote: > > In a private response to Peter, I directed him to NetBSD. NetBSD > contains some/most(?)/all(?) of the simple formula implementations. > I sent Peter the guts of ccosh as implemented by NetBSD (the simple > formula) and the current version of ccosh that Bruce and I had written. > The netbsd version is 15 lines (excluding the license). The bde+me > version is 91 lines (excluding license and initial comment). To be > fair, a large portion of those 91 lines are comments of the form > > /* > * cosh(+-Inf + I NaN) = +Inf + I d(NaN). > * > * cosh(+-Inf +- I Inf) = +Inf + I dNaN. > * The sign of Inf in the result is unspecified. Choice = always +. > * Raise the invalid floating-point exception. > * > * cosh(+-Inf + I y) = +Inf cos(y) +- I Inf sin(y) > */ > ... We also have a ~15 line version for ccosh[f]() only (after removing comments that are less detailed than the above). Howver, the error handling has only been checked for the float version, and the overflow handling is mostly nonexistent for all versions. Here is a simple version: % /* % * Hyperbolic cosine of a double complex argument. % * % * Most exceptional values are automatically correctly handled by the % * standard formula. See n1124.pdf for details. ^^^^^^^^^ This (draft) C99+ standard gives details like the above, except of course our choice of sign and our details of NaN handling). % */ % % #include % #include % % #include "../math_private.h" % % double complex % ccosh1(double complex z) % { % double x, y; % % x = creal(z); % y = cimag(z); % % /* % * This is subtler than it looks. We handle the cases x == 0 and % * y == 0 directly not for efficiency, but to avoid multiplications % * that don't work like we need. In these cases, the result must % * be almost pure real or a pure imaginary, except it has type % * float complex and its impure part may be -0. Multiplication of % * +-0 by an infinity or a NaN would give a NaN for the impure part, % * and would raise an unwanted exception. % * % * We depend on cos(y) and sin(y) never being precisely +-0 except % * when y is +-0 to prevent getting NaNs from other cases of % * +-Inf*+-0. This is true in infinite precision (since pi is % * irrational), and checking shows that it is also true after % * rounding to float precision. This is impossible to check in a reasonable time for double and higher precisions, but our implementation of accuracy for trig functions already depends on more (on certain bounding of the results away from 0). % */ % if (x == 0 && !isfinite(y)) % return (cpack(y - y, copysign(0, x * (y - y)))); % if (y == 0) % return (cpack(cosh(x), isnan(x) ? copysign(0, (x + x) * y) : % copysign(0, x) * y)); % if (isinf(x) && !isfinite(y)) % return (cpack(x * x, x * (y - y))); % return (cpack(cosh(x) * cos(y), sinh(x) * sin(y))); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Standard formulas like this almost work for this and for all elementary transcendental functions. There are obvious accuracy and overflow problems in such formulas. Here cosh(x) may overflow although all of the infinitely precise results are less than DBL_MAX. All these problems can be reduced by evaluating expressions in extra precision, but that would be slow, and no extra precision is availble for the long double versions. % } Bruce From bugmaster at FreeBSD.org Mon Aug 24 11:06:51 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 24 11:07:30 2009 Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org Message-ID: <200908241106.n7OB6o8o048473@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From ed at 80386.nl Mon Aug 24 17:40:51 2009 From: ed at 80386.nl (Ed Schouten) Date: Mon Aug 24 17:40:58 2009 Subject: mtx_lock_do_what_i_mean() Message-ID: <20090824174050.GI2829@hoeg.nl> Hi all, As some of you may already know, I'm writing a console driver for FreeBSD in my Perforce branch (newcons). What I don't like about console devices, but cannot be avoided, is that certain pieces of code need to be protected by spinning mutex, instead of default mutexes. This is because things like the terminal emulator need to be protected from concurrent access, which is likely to happen when printf() by the kernel and a write() on a TTY by a userspace process happen at the same time. It's not like the spin locks are held for an insane amount of time, but still, especially when doing things like scrolling the screen buffer, I think using default mutexes would be a lot better. I was thinking, in theory I'd only need to lock the first window of my console device instances with spin locks, because the other windows will never interact with the kernel message/debug console. I was thinking about locking the mutexes and using their lock classes to call the appropriate lock routine, but looking at the source, something tells me this won't work: | void | lock_spin(struct lock_object *lock, int how) | { | | panic("spin locks can only use msleep_spin"); | } So basically I'm sending this message to ask what I should do here. Is there a more elegant way to solve this? -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090824/3f1a6ba3/attachment.pgp From xcllnt at mac.com Mon Aug 24 21:05:18 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Mon Aug 24 21:05:24 2009 Subject: mtx_lock_do_what_i_mean() In-Reply-To: <20090824174050.GI2829@hoeg.nl> References: <20090824174050.GI2829@hoeg.nl> Message-ID: <2678DC6C-3E91-420A-B43D-02E0F1F853C5@mac.com> On Aug 24, 2009, at 10:40 AM, Ed Schouten wrote: > Hi all, > > As some of you may already know, I'm writing a console driver for > FreeBSD in my Perforce branch (newcons). What I don't like about > console > devices, but cannot be avoided, is that certain pieces of code need to > be protected by spinning mutex, instead of default mutexes. This is > because things like the terminal emulator need to be protected from > concurrent access, which is likely to happen when printf() by the > kernel > and a write() on a TTY by a userspace process happen at the same time. I would approach the problem differently: decouple printf() in the kernel from anything to which we have a TTY attached. Instead, look at printf() as a means to write to the message buffer only. Echoing things that go into the message buffer to the console becomes 1) optional (yay!), and 2) something you can do by going through the TTY layer (use a kthread or use a process [syslog]). Just a thought, -- Marcel Moolenaar xcllnt@mac.com From ed at 80386.nl Tue Aug 25 07:31:00 2009 From: ed at 80386.nl (Ed Schouten) Date: Tue Aug 25 07:31:06 2009 Subject: mtx_lock_do_what_i_mean() In-Reply-To: <2678DC6C-3E91-420A-B43D-02E0F1F853C5@mac.com> References: <20090824174050.GI2829@hoeg.nl> <2678DC6C-3E91-420A-B43D-02E0F1F853C5@mac.com> Message-ID: <20090825073057.GK2829@hoeg.nl> * Marcel Moolenaar wrote: > I would approach the problem differently: decouple printf() in the > kernel from anything to which we have a TTY attached. Instead, look > at printf() as a means to write to the message buffer only. Echoing > things that go into the message buffer to the console becomes 1) > optional (yay!), and 2) something you can do by going through the TTY > layer (use a kthread or use a process [syslog]). Yeah. That would be a lot better, but that means you still need to have a lot of code to make it work properly w.r.t. kernel panics: - When you're in the kernel debugger, you still need to have this synchronous programming interface to print data and read keyboard input. - In this context, you need to add extra code to flush the buffer before printing I think we could look at this approach somewhere in the future, but better not now. I'd rather not debug debugging interfaces. ;-) -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090825/8cbdda2f/attachment.pgp From kostikbel at gmail.com Tue Aug 25 08:57:34 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Tue Aug 25 08:57:41 2009 Subject: mtx_lock_do_what_i_mean() In-Reply-To: <20090825073057.GK2829@hoeg.nl> References: <20090824174050.GI2829@hoeg.nl> <2678DC6C-3E91-420A-B43D-02E0F1F853C5@mac.com> <20090825073057.GK2829@hoeg.nl> Message-ID: <20090825085726.GP9623@deviant.kiev.zoral.com.ua> On Tue, Aug 25, 2009 at 09:30:57AM +0200, Ed Schouten wrote: > I think we could look at this approach somewhere in the future, but > better not now. I'd rather not debug debugging interfaces. ;-) Would you use the lock/unlock function pointers in the appropriate structure ? See, for instance, the locking interface in kqueue subsystem, in particular, struct knlist and functions knlist_init and knlist_init_mtx. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090825/9d59a513/attachment.pgp From brde at optusnet.com.au Tue Aug 25 14:23:03 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Tue Aug 25 14:23:10 2009 Subject: mtx_lock_do_what_i_mean() In-Reply-To: <2678DC6C-3E91-420A-B43D-02E0F1F853C5@mac.com> References: <20090824174050.GI2829@hoeg.nl> <2678DC6C-3E91-420A-B43D-02E0F1F853C5@mac.com> Message-ID: <20090825205358.A40622@delplex.bde.org> On Mon, 24 Aug 2009, Marcel Moolenaar wrote: > On Aug 24, 2009, at 10:40 AM, Ed Schouten wrote: >> As some of you may already know, I'm writing a console driver for >> FreeBSD in my Perforce branch (newcons). What I don't like about console >> devices, but cannot be avoided, is that certain pieces of code need to >> be protected by spinning mutex, instead of default mutexes. This is Certain pieces cannot be protected by any mutex. >> because things like the terminal emulator need to be protected from >> concurrent access, which is likely to happen when printf() by the kernel >> and a write() on a TTY by a userspace process happen at the same time. These are the easy cases. The interesting cases are synchronous i/o in panic and debugger traps (NMI and non-interrupt related traps can also preempt even a spin mutex, but these shouldn't do console i/o except via panic). Mutex locking cannot work in these cases. At best you can ignore the mutex and proceed. In fact, no exclusive or shared locking can work. Atomic operations and reentrant code can work. Hardware and i/o operations to it are fundamentally non-reentrant, so console drivers must arrange for the i/o to clobber the hardware state as little as possible. Once you have made i/o in debugger traps work, other cases are trivial. Debugger trace traps are especially useful for testing reentrancy, since they are deterministic and occur on every instruction. Races that rarely occur in practice are easy to detect by single-stepping (with i/o) through every instruction in upper-level device initialization and i/o routines. > I would approach the problem differently: decouple printf() in the > kernel from anything to which we have a TTY attached. Instead, look > at printf() as a means to write to the message buffer only. Echoing > things that go into the message buffer to the console becomes 1) > optional (yay!), and 2) something you can do by going through the TTY > layer (use a kthread or use a process [syslog]). This is already implemented (TIOCCONS ioctl), but cannot work for serious debugging or panics, since it cannot provide synchronous i/o when it is most needed. Bruce From xcllnt at mac.com Tue Aug 25 18:58:23 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Tue Aug 25 18:58:29 2009 Subject: mtx_lock_do_what_i_mean() In-Reply-To: <20090825073057.GK2829@hoeg.nl> References: <20090824174050.GI2829@hoeg.nl> <2678DC6C-3E91-420A-B43D-02E0F1F853C5@mac.com> <20090825073057.GK2829@hoeg.nl> Message-ID: On Aug 25, 2009, at 12:30 AM, Ed Schouten wrote: > * Marcel Moolenaar wrote: >> I would approach the problem differently: decouple printf() in the >> kernel from anything to which we have a TTY attached. Instead, look >> at printf() as a means to write to the message buffer only. Echoing >> things that go into the message buffer to the console becomes 1) >> optional (yay!), and 2) something you can do by going through the TTY >> layer (use a kthread or use a process [syslog]). > > Yeah. That would be a lot better, but that means you still need to > have > a lot of code to make it work properly w.r.t. kernel panics: The debugger doesn't call printf(). It calls db_printf(). We already have everything in place to decouple the debugger from the problem and I would definitely not pull it in. The debugger is a problem all by itself... FYI, -- Marcel Moolenaar xcllnt@mac.com From brde at optusnet.com.au Wed Aug 26 06:35:45 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Wed Aug 26 06:35:52 2009 Subject: mtx_lock_do_what_i_mean() In-Reply-To: References: <20090824174050.GI2829@hoeg.nl> <2678DC6C-3E91-420A-B43D-02E0F1F853C5@mac.com> <20090825073057.GK2829@hoeg.nl> Message-ID: <20090826161941.B41435@delplex.bde.org> On Tue, 25 Aug 2009, Marcel Moolenaar wrote: > On Aug 25, 2009, at 12:30 AM, Ed Schouten wrote: > >> * Marcel Moolenaar wrote: >>> I would approach the problem differently: decouple printf() in the >>> kernel from anything to which we have a TTY attached. Instead, look >>> at printf() as a means to write to the message buffer only. Echoing >>> things that go into the message buffer to the console becomes 1) >>> optional (yay!), and 2) something you can do by going through the TTY >>> layer (use a kthread or use a process [syslog]). >> >> Yeah. That would be a lot better, but that means you still need to have >> a lot of code to make it work properly w.r.t. kernel panics: > > The debugger doesn't call printf(). It calls db_printf(). We > already have everything in place to decouple the debugger > from the problem and I would definitely not pull it in. The > debugger is a problem all by itself... Everything is in place to remove 0.1% of the coupling. Debugger i/o still normally goes to the same device as user and kernel i/o, so it is strongly coupled. Bruce From xcllnt at mac.com Wed Aug 26 06:57:12 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Wed Aug 26 06:57:18 2009 Subject: mtx_lock_do_what_i_mean() In-Reply-To: <20090826161941.B41435@delplex.bde.org> References: <20090824174050.GI2829@hoeg.nl> <2678DC6C-3E91-420A-B43D-02E0F1F853C5@mac.com> <20090825073057.GK2829@hoeg.nl> <20090826161941.B41435@delplex.bde.org> Message-ID: <6B5F99F6-3A66-4AE3-89BE-973F40AE34A9@mac.com> On Aug 25, 2009, at 11:35 PM, Bruce Evans wrote: > On Tue, 25 Aug 2009, Marcel Moolenaar wrote: > >> On Aug 25, 2009, at 12:30 AM, Ed Schouten wrote: >> >>> * Marcel Moolenaar wrote: >>>> I would approach the problem differently: decouple printf() in the >>>> kernel from anything to which we have a TTY attached. Instead, look >>>> at printf() as a means to write to the message buffer only. Echoing >>>> things that go into the message buffer to the console becomes 1) >>>> optional (yay!), and 2) something you can do by going through the >>>> TTY >>>> layer (use a kthread or use a process [syslog]). >>> Yeah. That would be a lot better, but that means you still need to >>> have >>> a lot of code to make it work properly w.r.t. kernel panics: >> >> The debugger doesn't call printf(). It calls db_printf(). We >> already have everything in place to decouple the debugger >> from the problem and I would definitely not pull it in. The >> debugger is a problem all by itself... > > Everything is in place to remove 0.1% of the coupling. Debugger i/o > still normally goes to the same device as user and kernel i/o, so it > is strongly coupled. That's a non sequitur. Sharing travel destinations does not mean that you travel together, for example. The fact that currently the console is used by both does not mean there's coupling. In fact, the debugger goes through the low-level console interface, whereas printf() gets redirected eventually to go through the TTY layer. Having printf() not even write to the console does not mean that the debugger cannot keep using the low-level console interfaces... -- Marcel Moolenaar xcllnt@mac.com From brde at optusnet.com.au Wed Aug 26 12:06:31 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Wed Aug 26 12:06:38 2009 Subject: mtx_lock_do_what_i_mean() In-Reply-To: <6B5F99F6-3A66-4AE3-89BE-973F40AE34A9@mac.com> References: <20090824174050.GI2829@hoeg.nl> <2678DC6C-3E91-420A-B43D-02E0F1F853C5@mac.com> <20090825073057.GK2829@hoeg.nl> <20090826161941.B41435@delplex.bde.org> <6B5F99F6-3A66-4AE3-89BE-973F40AE34A9@mac.com> Message-ID: <20090826192646.O10848@besplex.bde.org> On Tue, 25 Aug 2009, Marcel Moolenaar wrote: > On Aug 25, 2009, at 11:35 PM, Bruce Evans wrote: > >> On Tue, 25 Aug 2009, Marcel Moolenaar wrote: >> >>> On Aug 25, 2009, at 12:30 AM, Ed Schouten wrote: >>> >>>> * Marcel Moolenaar wrote: >>>>> I would approach the problem differently: decouple printf() in the >>>>> kernel from anything to which we have a TTY attached. Instead, look >>>>> at printf() as a means to write to the message buffer only. Echoing >>>>> things that go into the message buffer to the console becomes 1) >>>>> optional (yay!), and 2) something you can do by going through the TTY >>>>> layer (use a kthread or use a process [syslog]). >>>> Yeah. That would be a lot better, but that means you still need to have >>>> a lot of code to make it work properly w.r.t. kernel panics: >>> >>> The debugger doesn't call printf(). It calls db_printf(). We >>> already have everything in place to decouple the debugger >>> from the problem and I would definitely not pull it in. The >>> debugger is a problem all by itself... >> >> Everything is in place to remove 0.1% of the coupling. Debugger i/o >> still normally goes to the same device as user and kernel i/o, so it >> is strongly coupled. > > That's a non sequitur. Sharing travel destinations does > not mean that you travel together, for example. The coupling here occurs at the destination. > The fact that currently the console is used by both does > not mean there's coupling. In fact, the debugger goes > through the low-level console interface, whereas printf() > gets redirected eventually to go through the TTY layer. printf() goes through the low-level console interface in the same way as the debugger in most cases (unless the console has been redirected). > Having printf() not even write to the console does not > mean that the debugger cannot keep using the low-level > console interfaces... It just means that printf() would be slightly broken (no longer synchronous, and unusable in panic()...). It would remove only another 0.1% of the coupling for the low-level console interfaces, since the debugger must keep using them, and the requirements for working with debuggers are so strong that also working in other cases is trivial. Note that strong coupling is simplest here. If debugger i/o is in a separate module then it has a hard time even knowing the interrupted state. One impossibly difficult weakly-coupled case is when normal i/o is done by a propietary X driver using undocumented hardware features from userland, with some undocumented features active at the time of the interrupt. Non-debugger console i/o is also impossibly difficult in this case. FreeBSD doesn't attempt to support it, and uses cn*avail* interfaces to give null i/o and less than null ddb support. With all the i/o in the kernel, it is possible to guess the hardware and driver state by peeking at driver variables and hardware registers. With strong coupling, it is possible to do this robustly. Upper layers must cooperate by recording enough of their state in an atomic way. The coupling in lower layers then consists of using the records and knowing that they are sufficient. Bruce From xcllnt at mac.com Wed Aug 26 16:40:03 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Wed Aug 26 16:40:09 2009 Subject: mtx_lock_do_what_i_mean() In-Reply-To: <20090826192646.O10848@besplex.bde.org> References: <20090824174050.GI2829@hoeg.nl> <2678DC6C-3E91-420A-B43D-02E0F1F853C5@mac.com> <20090825073057.GK2829@hoeg.nl> <20090826161941.B41435@delplex.bde.org> <6B5F99F6-3A66-4AE3-89BE-973F40AE34A9@mac.com> <20090826192646.O10848@besplex.bde.org> Message-ID: On Aug 26, 2009, at 5:06 AM, Bruce Evans wrote: >>> Everything is in place to remove 0.1% of the coupling. Debugger i/o >>> still normally goes to the same device as user and kernel i/o, so it >>> is strongly coupled. >> >> That's a non sequitur. Sharing travel destinations does >> not mean that you travel together, for example. > > The coupling here occurs at the destination. Exactly: that's why I said everything is in place to change the destination of printf(). >> Having printf() not even write to the console does not >> mean that the debugger cannot keep using the low-level >> console interfaces... > > It just means that printf() would be slightly broken (no longer > synchronous, and unusable in panic()...). printf not being synchronous is actually what solves all the complexity. We don't need synchronous output in the normal case. Only for the "broken" case (i.e. kernel panic, no root FS), do we need synchronous output. It's the exceptional case. I belief common sense tells us to optimize for the common case. > Note that strong coupling is simplest here. I disagree. We've had various threads on this topic and they had the same theme: "we have this interlock and it's a problem. Help!" I belief that trying to solve the problem within the existing framework is not the solution, because I belief the framework itself is the problem. Rethinking it from the bottom-up helps to detangle and come up with a good implementation. > If debugger i/o is in a > separate module then it has a hard time even knowing the interrupted > state. One impossibly difficult weakly-coupled case is when normal > i/o is done by a propietary X driver using undocumented hardware > features from userland, with some undocumented features active at the > time of the interrupt. The question is: why try so hard to solve a problem that's specific to a case we all try our best to avoid? Isn't it much easier to say that debugger output and console are not the same so that you can run X on syscons and DDB over a serial interface and if all else fails: dump a kernel core and analyze the state offline. Having an in-kernel debugger is great, but it should be kept at "arms length" as much as possible. The moment you start sharing interfaces or mixing functionality you're setting yourself up for failure: either the debugger does not work in certain cases (running X is a perfect example of how the in-kernel debugger is totally useless) or you complicate the kernel unnecessarily. > Non-debugger console i/o is also impossibly > difficult in this case. FreeBSD doesn't attempt to support it, and > uses cn*avail* interfaces to give null i/o and less than null ddb > support. With all the i/o in the kernel, it is possible to guess the > hardware and driver state by peeking at driver variables and hardware > registers. With strong coupling, it is possible to do this robustly. That's not true. There's no robust way for the kernel debugger to use hardware that is under the console of process space. If anything: output is always interrupted and disrupted by the debugger, so even if the hardware is left in a consistent state, the actual content on the screen may be garbled. > Upper layers must cooperate by recording enough of their state in an > atomic way. The coupling in lower layers then consists of using the > records and knowing that they are sufficient. Upper layers include user space in some cases. The state of the 3D graphics accelerator is not something you want to have to worry about in the kernel. Though, you do want to know the "mode" if you want to write to the frame buffer. Graphical displays is our weakest point and given that there's no interest in fixing it, I can say that no matter what we do in the existing framework we will never have robust behaviour. Just my $0.02 of course... -- Marcel Moolenaar xcllnt@mac.com From brde at optusnet.com.au Wed Aug 26 22:07:49 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Wed Aug 26 22:07:57 2009 Subject: mtx_lock_do_what_i_mean() In-Reply-To: References: <20090824174050.GI2829@hoeg.nl> <2678DC6C-3E91-420A-B43D-02E0F1F853C5@mac.com> <20090825073057.GK2829@hoeg.nl> <20090826161941.B41435@delplex.bde.org> <6B5F99F6-3A66-4AE3-89BE-973F40AE34A9@mac.com> <20090826192646.O10848@besplex.bde.org> Message-ID: <20090827044818.D826@besplex.bde.org> On Wed, 26 Aug 2009, Marcel Moolenaar wrote: > On Aug 26, 2009, at 5:06 AM, Bruce Evans wrote: > >>>> Everything is in place to remove 0.1% of the coupling. Debugger i/o >>>> still normally goes to the same device as user and kernel i/o, so it >>>> is strongly coupled. >>> >>> That's a non sequitur. Sharing travel destinations does >>> not mean that you travel together, for example. >> >> The coupling here occurs at the destination. > > Exactly: that's why I said everything is in place to change the > destination of printf(). Except for printf()s in panic(). These can only be redirected to driver(s) similar to working console drivers would need similar complications to work. One thing that could be done now is reducing from multiple active broken console drivers to a single least-broken one for panics and debugging, or at least as a last effort for recursive panics. However, this doesn't help in the usual case where there is only 1 active console driver or in the fairly usual case where the user has only 1 set of console hardware. >>> Having printf() not even write to the console does not >>> mean that the debugger cannot keep using the low-level >>> console interfaces... >> >> It just means that printf() would be slightly broken (no longer >> synchronous, and unusable in panic()...). > > printf not being synchronous is actually what solves all > the complexity. We don't need synchronous output in the > normal case. Only for the "broken" case (i.e. kernel > panic, no root FS), do we need synchronous output. It's > the exceptional case. > > I belief common sense tells us to optimize for the common > case. We're not optimizing, but making the uncommon case actually work. >> Note that strong coupling is simplest here. > > I disagree. We've had various threads on this topic and > they had the same theme: "we have this interlock and it's > a problem. Help!" There is remarkably little understanding of the problem. The interlock is not a problem. It is the state being protected by the interlock that is a problem! A working console driver cannot just blow away the interrupted state, either hardware or software, and it cannot rely on the interrupt state being usable. > I belief that trying to solve the problem within the > existing framework is not the solution, because I belief > the framework itself is the problem. Rethinking it from > the bottom-up helps to detangle and come up with a good > implementation. I've outlined a good solution many times and implemented part of it in FreeBSD and all of it in my debugger's i/o routines: - switch to and from console i/o mode when directed to by cn_dbctl(). Natural switch points for ddb are on entry to and exit from interactive mode. Natural switch points for other i/o are not so clear -- switching for every printf() is too much. - make the switches nest as deep as necessary (3 or 4 levels is enough) - switches involve: on entry: - save all state (hardware and software) not already saved. Here it helps for upper layers to not have much state in the air. Here it is essential for upper layers to have recorded their state in some atomic way. - initialize all state (hardware and software) used by console driver. Here it helps for the upper layers to have initialized most of the state. You can always reinitialize everything, but then restoring the interrupted state will be hard. on exit: - restore as much state (hardware and software) as possible. Except, if the console i/o routines wrote to the same physical console that non-console routines write to, and this physical console is something like a frame buffer, then the something-like-a-frame-buffer state must not be restored, so that you can actually read the output. Debugger frame buffer output should go to a separate virtual console, possibly in a different video mode. If the video mode is not switched, then the hardware part of the switch involves mainly copying the frame buffer out and in. If the video mode is switched, then the switch involves reinitializing lots of hardware. Switching to a fixed mode is probably still simpler than supporting console output in all possible interrupted modes. Writing to a separate virtual console is not so good for non-debugger output, since the output needs to be made visible at some point and switching the console on every printf() is no good. Switching back and forth on every printf() is worst -- it makes the screen flicker, and the output is still invisible most of the time. IIRC, old console drivers (codrv and pcvt) wrote to ttyv0 and forced a switch there. This was inconvenient. It is probably best to always printf() to a separate virtual console (different from the debugger one), and also to the current console if possible and implemented. - after switching to console mode, the actual i/o is trival, at least if you always switch the interrupted mode to a fixed one if the interrupted mode is different. >> If debugger i/o is in a >> separate module then it has a hard time even knowing the interrupted >> state. One impossibly difficult weakly-coupled case is when normal >> i/o is done by a propietary X driver using undocumented hardware >> features from userland, with some undocumented features active at the >> time of the interrupt. > > The question is: why try so hard to solve a problem that's > specific to a case we all try our best to avoid? Isn't it > much easier to say that debugger output and console are not > the same so that you can run X on syscons and DDB over a > serial interface and if all else fails: dump a kernel core > and analyze the state offline. Some users and/or developers don't have or want to set up multiple i/o devices just for consoles. > Having an in-kernel debugger is great, but it should be > kept at "arms length" as much as possible. The moment you > start sharing interfaces or mixing functionality you're > setting yourself up for failure: either the debugger does > not work in certain cases (running X is a perfect example > of how the in-kernel debugger is totally useless) or you > complicate the kernel unnecessarily. Well, once you have working console i/o for debuggers, you almost have it for panic(), and you don't have to worry about printf() from interrupt handlers that interrupt an inadequately locked upper-level i/o routine corrupting the upper level. Syscons' spltty() (and missing) locking was always inadequate for this (it needed to be splhigh() for much the same reasons that it is now a spin mutex, but this is ugly). Working console i/o requires forces you to find most of the inadequate locking and helps find some of it (single-step through the driver until it crashes). >> Non-debugger console i/o is also impossibly >> difficult in this case. FreeBSD doesn't attempt to support it, and >> uses cn*avail* interfaces to give null i/o and less than null ddb >> support. With all the i/o in the kernel, it is possible to guess the >> hardware and driver state by peeking at driver variables and hardware >> registers. With strong coupling, it is possible to do this robustly. > > That's not true. There's no robust way for the kernel debugger > to use hardware that is under the console of process space. > If anything: output is always interrupted and disrupted by the > debugger, so even if the hardware is left in a consistent state, > the actual content on the screen may be garbled. The amount of disruption is hardware-dependent. Losing a couple of characters is unimportant, and is also avoidable for frame buffer type hardware. Switching the console and its mode to avoid disrupting output has been routine in at least userland debuggers for at least 20 years. Userland debuggers have fewer problems doing this since they can't interrupt hardware mode switches, but their switch is still a heavyweight operation. OTOH, kernel debuggers can avoid the mode switch and possibly the console switch in most cases since they are close to the driver (if the driver is entirely in the kernel). >> Upper layers must cooperate by recording enough of their state in an >> atomic way. The coupling in lower layers then consists of using the >> records and knowing that they are sufficient. > > Upper layers include user space in some cases. The state of the > 3D graphics accelerator is not something you want to have to worry > about in the kernel. Though, you do want to know the "mode" if > you want to write to the frame buffer. Graphical displays is our > weakest point and given that there's no interest in fixing it, Yes, I don't want to support any userland graphics driver. > I can say that no matter what we do in the existing framework we > will never have robust behaviour. Actually, it can be made robust (but not working) fairly easily: - clear the device's cn_avail_mask bit while in critical regions. This could be implemented fairly easily using the macro for locking the critical regions. - fix the placement of cnunavailable() in ddb, so that breakpoints in the instruction stream aren't fatal when they are hit while the console is unavailable. - the cn_avail_mask bit is managed by calling cnavail(). It is not very efficient, despite having no locking whatsoever. Fix its locking and try to optimize it. The whole of kern_cons.c has no locking except for broken locking in cnputs(). Normal mutex locking cannot be used, but cnputs() uses it. mtx_trylock() would be robust (but not working) in cnputs(). Accesses to cn_avail_mask need a bit more than atomicity, since there is another avail bit in cn_flags. - fix many other races involving accesses to cn_avail_mask. Oops. there are some that cannot be made robust fairly easily. There is 1 involving checking cnunavail() and acting on its result. This one is mosty dormant. Active ones include cnremove() called from the console control sysctl racing with cnavail() called from upper layers of device drivers that support consoles. Bruce From attilio at freebsd.org Sat Aug 29 02:37:24 2009 From: attilio at freebsd.org (Attilio Rao) Date: Sat Aug 29 02:37:31 2009 Subject: [PATCH] VFS KPI/API versioning Message-ID: <3bbf2fe10908281904l6f8119a5l2daa301016eac8ef@mail.gmail.com> Often I found as it would have been useful to verify, mostly at run-time, of a feature of the VFS was supported and I quickly thought that having a run-time check for VFS versioning would not be a bad idea. In order to do that, I made the following patch: http://www.freebsd.org/~attilio/vfs_modload.diff which basically builds the vfs layer as a module adding a version number that can be checked for filesystems/modules willing to load in order to see if a specific feature is supported. Obviously I didn't add an entry in the modules/ neither possibility to unload/shutdown the module because we would not be willing to have such operations (or a run-time load of the vfs). Something that concerned me is also the mis-usage of the VFS_VERSION macro, which can be easilly used at compile time in order to determine if a feature is present or not. Basically, I have no idea by when it doesn't get updated and if it has ever been checked in our codes. It seems to use a random number as the start count, while it could have been handled differently. Maybe it would be the case to start taking care of that too, which can be an interesting tool. Can you comment on the patch? If you think it is a good idea I will commit right away on -CURRENT and STABLE_8. Attilio -- Peace can only be achieved by understanding - A. Einstein From roam at ringlet.net Sat Aug 29 14:25:10 2009 From: roam at ringlet.net (Peter Pentchev) Date: Sat Aug 29 14:25:17 2009 Subject: [PATCH] VFS KPI/API versioning In-Reply-To: <3bbf2fe10908281904l6f8119a5l2daa301016eac8ef@mail.gmail.com> References: <3bbf2fe10908281904l6f8119a5l2daa301016eac8ef@mail.gmail.com> Message-ID: <20090829142507.GA1141@straylight.m.ringlet.net> On Sat, Aug 29, 2009 at 04:04:55AM +0200, Attilio Rao wrote: [snip] > Something that concerned me is also the mis-usage of the VFS_VERSION > macro, which can be easilly used at compile time in order to determine > if a feature is present or not. Basically, I have no idea by when it > doesn't get updated and if it has ever been checked in our codes. It > seems to use a random number as the start count, while it could have > been handled differently. Maybe it would be the case to start taking > care of that too, which can be an interesting tool. Quite offtopic, just a note about the "random number as the start count" part - it's not exactly random; take a "fgrep 1966" to calendar.freebsd ;) G'luck, Peter -- Peter Pentchev roam@ringlet.net roam@space.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This would easier understand fewer had omitted. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090829/337d82a2/attachment.pgp From kabaev at gmail.com Sun Aug 30 02:28:42 2009 From: kabaev at gmail.com (Alexander Kabaev) Date: Sun Aug 30 02:28:48 2009 Subject: [PATCH] VFS KPI/API versioning In-Reply-To: <3bbf2fe10908281904l6f8119a5l2daa301016eac8ef@mail.gmail.com> References: <3bbf2fe10908281904l6f8119a5l2daa301016eac8ef@mail.gmail.com> Message-ID: <20090829220532.47404497@kan.dnsalias.net> The patch looks simple enough and I think is a good idea. As for VFS_VERSION, I am yet to see the evidence of it ever being used by anybody. -- Alexander Kabaev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090830/dded5457/signature.pgp From MDaemon at mail.electroservice.kiev.ua Sun Aug 30 18:14:15 2009 From: MDaemon at mail.electroservice.kiev.ua (MDaemon at mail.electroservice.kiev.ua) Date: Sun Aug 30 18:14:22 2009 Subject: Permanent Delivery Failure Message-ID: The attached message had PERMANENT fatal delivery errors! After one or more unsuccessful delivery attempts the attached message has been removed from the mail queue on this server. The number and frequency of delivery attempts are determined by local configuration parameters. YOUR MESSAGE WAS NOT DELIVERED TO ONE OR MORE RECIPIENTS! --- Session Transcript --- Sun 2009-08-30 20:43:30: Parsing message Sun 2009-08-30 20:43:30: * From: freebsd-arch@FreeBSD.org Sun 2009-08-30 20:43:30: * To: vgeaaaaa@electroservice.kiev.ua Sun 2009-08-30 20:43:30: * Subject: [***SPAM*** Score/Req: 7.3/3.0] ??????? ? ??????? - ???? ??????? ???????? "17336" "we" Sun 2009-08-30 20:43:30: * Message-ID: <190961466.20090123211403@FreeBSD.org> Sun 2009-08-30 20:43:30: * Route slip host: ex-srv01.electroservice.kiev.ua Sun 2009-08-30 20:43:30: * Route slip port: 25 Sun 2009-08-30 20:43:30: Attempting SMTP connection to [ex-srv01.electroservice.kiev.ua] Sun 2009-08-30 20:43:30: Resolving MX records for [ex-srv01.electroservice.kiev.ua] (DNS Server: 192.168.100.5)... Sun 2009-08-30 20:43:30: * P=010 S=000 D=ex-srv01.electroservice.kiev.ua TTL=(60) MX=[ex-srv01.electroservice.kiev.ua] {192.168.100.7} Sun 2009-08-30 20:43:30: Attempting SMTP connection to [192.168.100.7:25] Sun 2009-08-30 20:43:30: Waiting for socket connection... Sun 2009-08-30 20:43:30: * Connection established (192.168.100.3:28699 -> 192.168.100.7:25) Sun 2009-08-30 20:43:30: Waiting for protocol to start... Sun 2009-08-30 20:43:30: <-- 220 Ex-Srv01.electroservice.kiev.ua Microsoft ESMTP MAIL Service, Version: 6.0.3790.3959 ready at Sun, 30 Aug 2009 20:43:29 +0300 Sun 2009-08-30 20:43:30: --> EHLO mail.electroservice.kiev.ua Sun 2009-08-30 20:43:30: <-- 250-Ex-Srv01.electroservice.kiev.ua Hello [192.168.100.3] Sun 2009-08-30 20:43:30: <-- 250-TURN Sun 2009-08-30 20:43:30: <-- 250-SIZE Sun 2009-08-30 20:43:30: <-- 250-ETRN Sun 2009-08-30 20:43:30: <-- 250-PIPELINING Sun 2009-08-30 20:43:30: <-- 250-DSN Sun 2009-08-30 20:43:30: <-- 250-ENHANCEDSTATUSCODES Sun 2009-08-30 20:43:30: <-- 250-8bitmime Sun 2009-08-30 20:43:30: <-- 250-BINARYMIME Sun 2009-08-30 20:43:30: <-- 250-CHUNKING Sun 2009-08-30 20:43:30: <-- 250-VRFY Sun 2009-08-30 20:43:30: <-- 250-X-EXPS GSSAPI NTLM Sun 2009-08-30 20:43:30: <-- 250-AUTH GSSAPI NTLM Sun 2009-08-30 20:43:30: <-- 250-X-LINK2STATE Sun 2009-08-30 20:43:30: <-- 250-XEXCH50 Sun 2009-08-30 20:43:30: <-- 250 OK Sun 2009-08-30 20:43:30: --> MAIL From: SIZE=21136 Sun 2009-08-30 20:43:30: <-- 250 2.1.0 freebsd-arch@FreeBSD.org....Sender OK Sun 2009-08-30 20:43:30: --> RCPT To: Sun 2009-08-30 20:43:30: <-- 550 5.1.1 User unknown Sun 2009-08-30 20:43:30: --> QUIT --- End Transcript --- : Message contains [1] file attachments -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/octet-stream Size: 21136 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090830/f842733d/attachment.obj From bugmaster at FreeBSD.org Mon Aug 31 11:07:01 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 31 11:07:30 2009 Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org Message-ID: <200908311107.n7VB70hB070469@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From jhb at freebsd.org Mon Aug 31 11:31:53 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Aug 31 11:32:00 2009 Subject: [PATCH] VFS KPI/API versioning In-Reply-To: <3bbf2fe10908281904l6f8119a5l2daa301016eac8ef@mail.gmail.com> References: <3bbf2fe10908281904l6f8119a5l2daa301016eac8ef@mail.gmail.com> Message-ID: <200908310731.24021.jhb@freebsd.org> On Friday 28 August 2009 10:04:55 pm Attilio Rao wrote: > Often I found as it would have been useful to verify, mostly at > run-time, of a feature of the VFS was supported and I quickly thought > that having a run-time check for VFS versioning would not be a bad > idea. > In order to do that, I made the following patch: > http://www.freebsd.org/~attilio/vfs_modload.diff You don't have to have an actual DECLARE_MODULE() to use MODULE_VERSION(). Given that, you can simplify this patch down to a single line that just adds the MODULE_VERSION(). -- John Baldwin From delphij at delphij.net Mon Aug 31 22:35:46 2009 From: delphij at delphij.net (Xin LI) Date: Mon Aug 31 22:35:54 2009 Subject: Import X11/NetBSD/OpenBSD's x86emu? Message-ID: <4A9C4FF4.6030809@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, There is some recent discussion about enabling VESA on amd64, by importing OpenBSD's x86emu (which originates from X11 and then imported into NetBSD, then OpenBSD). The x86emu code implements a virtual machine for 80386's real mode in < 9kLoC, and was ported to FreeBSD. Then, the current code for VESA has been modified to have the VESA code run inside the emulator, thus solved the problem that there is no VM86 support when we are in long mode. I'd like to give this a shoot but if there is any objections, please let me know. The patches can be obtained from: ftp://ftp.lissyara.su/users/Guest/vesa/ Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkqcT/QACgkQi+vbBBjt66B81gCgtyHBodCx9LY5uqfGaeRYTInn w+IAoLIhhKXhIP/CHTf+AsqVZUldolIO =Rqgi -----END PGP SIGNATURE-----