From imp at bsdimp.com Sun Jun 1 18:25:33 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Sun Jun 1 18:25:35 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled In-Reply-To: <20080526162427.X26343@fledge.watson.org> References: <5D4AF8D7-88A7-4197-A0FE-7CA992EE5F96@FreeBSD.org> <483AD498.6070207@FreeBSD.org> <20080526162427.X26343@fledge.watson.org> Message-ID: <20080601.122524.114765121.imp@bsdimp.com> In message: <20080526162427.X26343@fledge.watson.org> Robert Watson writes: : : On Mon, 26 May 2008, Bruce M. Simpson wrote: : : >> Given that this is (a) 2008 and (b) 8.x we're talking about, are there : >> really that many consumers of SLIP to warrant it being carried forward at : >> all? : > : > It's kind of a basic. [C]SLIP has been historically handy to have around for : > situations which warrant it. Mind you, given that we have had tun(4) in the : > tree for years now, a userland implementation of SLIP is possible. : > : > As with all of these things it's down to someone sitting down and doing it. : > : > I'm not volunteering to support any of this as I don't use it myself (got : > enough on my plate), merely pointing out that support for SLIP in a system : > is something many people have taken for granted over the years, and for : > prototyping something or providing IP over a simple serial link without the : > configuration overhead of PPP, SLIP is something someone might be using. : > : > P.S. ahc(4) is commodity hardware, I think it can stay right where it is : > thank-you. : : My suspicion is that getting SLIP basically working in userspace is fairly : straight forward, SLiRP and friends have been doing this for years. I made my living for about a year working on TIA, which was a portable, userland implementation of PPP and SLIP/CSLIP. This was in about 1995 or so. It isn't that hard... : SLIP has its subtleties, but the current implementation is relatively : straight-forward, well-documented, etc. Yes, especially CSLIP. But frankly, they are a whole lot easier than PPP to get up and going... Warner From imp at bsdimp.com Sun Jun 1 18:34:45 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Sun Jun 1 18:34:51 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled In-Reply-To: <483C2666.7010608@FreeBSD.org> References: <45633.1211870269@critter.freebsd.dk> <20080527064253.GG64397@hoeg.nl> <483C2666.7010608@FreeBSD.org> Message-ID: <20080601.123351.-950433793.imp@bsdimp.com> In message: <483C2666.7010608@FreeBSD.org> "Bruce M. Simpson" writes: : Other than that, line disciplines can go away. In the past I've uesd line disciplines to implement a keyboard driver for the Apple Newton Keyboard (serial protocol) so I could use it at any point after the loader (the system didn't run X11, so I couldn't use the X11 driver I wrote there). This system has been retired, and I don't think I ever forward ported them past about 3.mumble, if even that far. This code is badly decayed, and I have no requirement that it continues to work. But I know similar techniques are used in some embedded systems. Expect some delayed complaining if they go away entirely. But that may be OK given we're ridding tty of Giant. Now, if we could only sort out the syscons/keyboard/mouse mess... Warner From phk at phk.freebsd.dk Sun Jun 1 21:01:25 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sun Jun 1 21:01:28 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled In-Reply-To: Your message of "Sun, 01 Jun 2008 12:33:51 CST." <20080601.123351.-950433793.imp@bsdimp.com> Message-ID: <2204.1212354080@critter.freebsd.dk> In message <20080601.123351.-950433793.imp@bsdimp.com>, "M. Warner Losh" writes : >In the past I've uesd line disciplines to implement a keyboard driver >for the Apple Newton Keyboard (serial protocol) [...] But shouldn't you have used uart(4) for 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 ed at 80386.nl Sun Jun 1 21:58:01 2008 From: ed at 80386.nl (Ed Schouten) Date: Sun Jun 1 21:58:04 2008 Subject: all mutexes -> read-write locks? In-Reply-To: <483EE7D5.5050408@elischer.org> References: <483EE7D5.5050408@elischer.org> Message-ID: <20080601215759.GN64397@hoeg.nl> Hello Julian, * Julian Elischer wrote: > it has been mentioned several times that through the evolution of the > locking primitives it has come to be that mutexes and exclusively > acquired reader-writer locks are almost the same in terms of overhead > and that it might be a good move to define all mutexes to be > actually just that. > > this would allow people to slowly go through the system, catching low > hanging fruit by converting some of the mutex operations to reader > acquisitions wherever a writer is not required, thus reducing general > system contention. > > Is there any thought on this? Last I heard jhb had confirmed that it > was feasible.. If this is going to be done, could we have mtx_* macro's pointing to the proper read/write ops? I know, it's just names, but I think most novice FreeBSD kernel hackers will almost instantaneously figure out what 'mtx' stands for. Why not make read/write locking a fundamental part of 'mtx' itself, if it doesn't introduce much overhead? -- 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/20080601/53116c75/attachment.pgp From julian at elischer.org Mon Jun 2 05:09:31 2008 From: julian at elischer.org (Julian Elischer) Date: Mon Jun 2 05:09:35 2008 Subject: all mutexes -> read-write locks? In-Reply-To: References: <483EE7D5.5050408@elischer.org> <20080601215759.GN64397@hoeg.nl> Message-ID: <4843808A.2060501@elischer.org> Daniel Eischen wrote: > On Sun, 1 Jun 2008, Ed Schouten wrote: > >> Hello Julian, >> >> * Julian Elischer wrote: >>> it has been mentioned several times that through the evolution of the >>> locking primitives it has come to be that mutexes and exclusively >>> acquired reader-writer locks are almost the same in terms of overhead >>> and that it might be a good move to define all mutexes to be >>> actually just that. >>> >>> this would allow people to slowly go through the system, catching low >>> hanging fruit by converting some of the mutex operations to reader >>> acquisitions wherever a writer is not required, thus reducing general >>> system contention. >>> >>> Is there any thought on this? Last I heard jhb had confirmed that it >>> was feasible.. >> >> If this is going to be done, could we have mtx_* macro's pointing to the >> proper read/write ops? I know, it's just names, but I think most novice >> FreeBSD kernel hackers will almost instantaneously figure out what 'mtx' >> stands for. > > Yes, mutex (mtx) is known very well. > > I don't think changing all mutex operations to rdlock operations > is wise. They are two different animals, regardless of their > implementation. Mutexes are very commonly used in device drivers, > at least outside of FreeBSD. And just because our current > implementation of them are the same as rwlocks doesn't mean that > it will always be the same in the future. > so let's imagine that mutexes dissappear... :-) From eischen at vigrid.com Mon Jun 2 05:20:24 2008 From: eischen at vigrid.com (Daniel Eischen) Date: Mon Jun 2 05:20:29 2008 Subject: all mutexes -> read-write locks? In-Reply-To: <20080601215759.GN64397@hoeg.nl> References: <483EE7D5.5050408@elischer.org> <20080601215759.GN64397@hoeg.nl> Message-ID: On Sun, 1 Jun 2008, Ed Schouten wrote: > Hello Julian, > > * Julian Elischer wrote: >> it has been mentioned several times that through the evolution of the >> locking primitives it has come to be that mutexes and exclusively >> acquired reader-writer locks are almost the same in terms of overhead >> and that it might be a good move to define all mutexes to be >> actually just that. >> >> this would allow people to slowly go through the system, catching low >> hanging fruit by converting some of the mutex operations to reader >> acquisitions wherever a writer is not required, thus reducing general >> system contention. >> >> Is there any thought on this? Last I heard jhb had confirmed that it >> was feasible.. > > If this is going to be done, could we have mtx_* macro's pointing to the > proper read/write ops? I know, it's just names, but I think most novice > FreeBSD kernel hackers will almost instantaneously figure out what 'mtx' > stands for. Yes, mutex (mtx) is known very well. I don't think changing all mutex operations to rdlock operations is wise. They are two different animals, regardless of their implementation. Mutexes are very commonly used in device drivers, at least outside of FreeBSD. And just because our current implementation of them are the same as rwlocks doesn't mean that it will always be the same in the future. -- DE From eischen at vigrid.com Mon Jun 2 05:27:57 2008 From: eischen at vigrid.com (Daniel Eischen) Date: Mon Jun 2 05:28:36 2008 Subject: all mutexes -> read-write locks? In-Reply-To: <4843808A.2060501@elischer.org> References: <483EE7D5.5050408@elischer.org> <20080601215759.GN64397@hoeg.nl> <4843808A.2060501@elischer.org> Message-ID: On Sun, 1 Jun 2008, Julian Elischer wrote: > Daniel Eischen wrote: >> On Sun, 1 Jun 2008, Ed Schouten wrote: >> >>> Hello Julian, >>> >>> * Julian Elischer wrote: >>>> it has been mentioned several times that through the evolution of the >>>> locking primitives it has come to be that mutexes and exclusively >>>> acquired reader-writer locks are almost the same in terms of overhead >>>> and that it might be a good move to define all mutexes to be >>>> actually just that. >>>> >>>> this would allow people to slowly go through the system, catching low >>>> hanging fruit by converting some of the mutex operations to reader >>>> acquisitions wherever a writer is not required, thus reducing general >>>> system contention. >>>> >>>> Is there any thought on this? Last I heard jhb had confirmed that it >>>> was feasible.. >>> >>> If this is going to be done, could we have mtx_* macro's pointing to the >>> proper read/write ops? I know, it's just names, but I think most novice >>> FreeBSD kernel hackers will almost instantaneously figure out what 'mtx' >>> stands for. >> >> Yes, mutex (mtx) is known very well. >> >> I don't think changing all mutex operations to rdlock operations >> is wise. They are two different animals, regardless of their >> implementation. Mutexes are very commonly used in device drivers, >> at least outside of FreeBSD. And just because our current >> implementation of them are the same as rwlocks doesn't mean that >> it will always be the same in the future. >> > > so let's imagine that mutexes dissappear... > :-) I'd rather not. What do you have against them? Their API is simple enough to use. If there is code that really wants to have multiple readers, by all means change it to use rwlocks. Take a look at Solaris kernel mutexes and see how you can init a mutex that is to be used in an interrupt handler. -- DE From julian at elischer.org Mon Jun 2 07:11:03 2008 From: julian at elischer.org (Julian Elischer) Date: Mon Jun 2 07:11:08 2008 Subject: all mutexes -> read-write locks? In-Reply-To: References: <483EE7D5.5050408@elischer.org> <20080601215759.GN64397@hoeg.nl> <4843808A.2060501@elischer.org> Message-ID: <48439D06.6020408@elischer.org> Daniel Eischen wrote: > On Sun, 1 Jun 2008, Julian Elischer wrote: > >> Daniel Eischen wrote: >>> On Sun, 1 Jun 2008, Ed Schouten wrote: >>> >>>> Hello Julian, >>>> >>>> * Julian Elischer wrote: >>>>> it has been mentioned several times that through the evolution of the >>>>> locking primitives it has come to be that mutexes and exclusively >>>>> acquired reader-writer locks are almost the same in terms of overhead >>>>> and that it might be a good move to define all mutexes to be >>>>> actually just that. >>>>> >>>>> this would allow people to slowly go through the system, catching low >>>>> hanging fruit by converting some of the mutex operations to reader >>>>> acquisitions wherever a writer is not required, thus reducing general >>>>> system contention. >>>>> >>>>> Is there any thought on this? Last I heard jhb had confirmed that it >>>>> was feasible.. >>>> >>>> If this is going to be done, could we have mtx_* macro's pointing to >>>> the >>>> proper read/write ops? I know, it's just names, but I think most novice >>>> FreeBSD kernel hackers will almost instantaneously figure out what >>>> 'mtx' >>>> stands for. >>> >>> Yes, mutex (mtx) is known very well. >>> >>> I don't think changing all mutex operations to rdlock operations >>> is wise. They are two different animals, regardless of their >>> implementation. Mutexes are very commonly used in device drivers, >>> at least outside of FreeBSD. And just because our current >>> implementation of them are the same as rwlocks doesn't mean that >>> it will always be the same in the future. >>> >> >> so let's imagine that mutexes dissappear... >> :-) > > I'd rather not. What do you have against them? People use them without thinking about whether they need to be so strict. > Their API is simple > enough to use. If there is code that really wants to have multiple > readers, by all means change it to use rwlocks. yes but we have a lot of code that uses mutexes.. changing it would allow a slow transition to using rw locks. > > Take a look at Solaris kernel mutexes and see how you can init > a mutex that is to be used in an interrupt handler. how does that help making more things use read locking? > From bugmaster at FreeBSD.org Mon Jun 2 11:06:45 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 2 11:06:54 2008 Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org Message-ID: <200806021106.m52B6j3u093099@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From gnn at neville-neil.com Mon Jun 2 15:38:18 2008 From: gnn at neville-neil.com (George V. Neville-Neil) Date: Mon Jun 2 15:38:22 2008 Subject: all mutexes -> read-write locks? In-Reply-To: <48439D06.6020408@elischer.org> References: <483EE7D5.5050408@elischer.org> <20080601215759.GN64397@hoeg.nl> <4843808A.2060501@elischer.org> <48439D06.6020408@elischer.org> Message-ID: At Mon, 02 Jun 2008 00:11:02 -0700, julian wrote: > > Daniel Eischen wrote: > > I'd rather not. What do you have against them? > > People use them without thinking about whether they need to be so > strict. This is an age old problem that removing mutexes will never fix. We could add documentation to the manual pages though saying, "Do you really really need this?" > > Their API is simple enough to use. If there is code that really > > wants to have multiple readers, by all means change it to use > > rwlocks. > > > yes but we have a lot of code that uses mutexes.. changing it would > allow a slow transition to using rw locks. We will likely have to do that ourselves. Sorry, but this is a Sisyphean task, and removing mutexes will not prevent the rock from falling back upon us again. Best, George From eischen at vigrid.com Mon Jun 2 17:14:30 2008 From: eischen at vigrid.com (Daniel Eischen) Date: Mon Jun 2 17:14:34 2008 Subject: all mutexes -> read-write locks? In-Reply-To: <48439D06.6020408@elischer.org> References: <483EE7D5.5050408@elischer.org> <20080601215759.GN64397@hoeg.nl> <4843808A.2060501@elischer.org> <48439D06.6020408@elischer.org> Message-ID: On Mon, 2 Jun 2008, Julian Elischer wrote: > Daniel Eischen wrote: >> On Sun, 1 Jun 2008, Julian Elischer wrote: >> >>> Daniel Eischen wrote: >>>> On Sun, 1 Jun 2008, Ed Schouten wrote: >>>> >>>>> Hello Julian, >>>>> >>>>> * Julian Elischer wrote: >>>>>> it has been mentioned several times that through the evolution of the >>>>>> locking primitives it has come to be that mutexes and exclusively >>>>>> acquired reader-writer locks are almost the same in terms of overhead >>>>>> and that it might be a good move to define all mutexes to be >>>>>> actually just that. >>>>>> >>>>>> this would allow people to slowly go through the system, catching low >>>>>> hanging fruit by converting some of the mutex operations to reader >>>>>> acquisitions wherever a writer is not required, thus reducing general >>>>>> system contention. >>>>>> >>>>>> Is there any thought on this? Last I heard jhb had confirmed that it >>>>>> was feasible.. >>>>> >>>>> If this is going to be done, could we have mtx_* macro's pointing to the >>>>> proper read/write ops? I know, it's just names, but I think most novice >>>>> FreeBSD kernel hackers will almost instantaneously figure out what 'mtx' >>>>> stands for. >>>> >>>> Yes, mutex (mtx) is known very well. >>>> >>>> I don't think changing all mutex operations to rdlock operations >>>> is wise. They are two different animals, regardless of their >>>> implementation. Mutexes are very commonly used in device drivers, >>>> at least outside of FreeBSD. And just because our current >>>> implementation of them are the same as rwlocks doesn't mean that >>>> it will always be the same in the future. >>>> >>> >>> so let's imagine that mutexes dissappear... >>> :-) >> >> I'd rather not. What do you have against them? > > People use them without thinking about whether they need to be so > strict. > >> Their API is simple >> enough to use. If there is code that really wants to have multiple >> readers, by all means change it to use rwlocks. > > > yes but we have a lot of code that uses mutexes.. changing it would allow a > slow transition to using rw locks. > >> >> Take a look at Solaris kernel mutexes and see how you can init >> a mutex that is to be used in an interrupt handler. > > how does that help making more things use read locking? It doesn't, it shows one reason why mutexes can be different than read/write locks. I don't see how most low-level leaf drivers can make use of read/write locks. All they want to do is prevent simultaneous access to a device and setup I/O operations. By keeping the mutex and rwlock APIs separate regardless of their implementation, you allow the code to specify what kind of locking it wants. If you convert all mutexes to rwlocks you lose this information and it makes it harder to go back again. On the other hand, if you s/mtx_foo/rw_foo/, you still have to analyze the code to tell whether or not you can truly turn them into simultaneous read locks. So what is the harm in analyzing the code first, and then converting it to rwlocks IFF it can make use of it? -- DE From phk at phk.freebsd.dk Mon Jun 2 17:34:41 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon Jun 2 17:34:43 2008 Subject: all mutexes -> read-write locks? In-Reply-To: Your message of "Mon, 02 Jun 2008 13:14:10 -0400." Message-ID: <6571.1212428077@critter.freebsd.dk> In message , Daniel Eischen wri tes: >It doesn't, it shows one reason why mutexes can be different >than read/write locks. Agreed. There is no easy way to determine which mutexes can be rw_locks, so take the correct route: education. -- 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 alfred at freebsd.org Mon Jun 2 17:35:38 2008 From: alfred at freebsd.org (Alfred Perlstein) Date: Mon Jun 2 17:35:40 2008 Subject: all mutexes -> read-write locks? In-Reply-To: References: <483EE7D5.5050408@elischer.org> <20080601215759.GN64397@hoeg.nl> <4843808A.2060501@elischer.org> <48439D06.6020408@elischer.org> Message-ID: <20080602171946.GJ48790@elvis.mu.org> * Daniel Eischen [080602 10:14] wrote: > On Mon, 2 Jun 2008, Julian Elischer wrote: > > > >how does that help making more things use read locking? > > It doesn't, it shows one reason why mutexes can be different > than read/write locks. > > I don't see how most low-level leaf drivers can make use of > read/write locks. All they want to do is prevent simultaneous > access to a device and setup I/O operations. > > By keeping the mutex and rwlock APIs separate regardless of > their implementation, you allow the code to specify what kind > of locking it wants. If you convert all mutexes to rwlocks > you lose this information and it makes it harder to go back > again. On the other hand, if you s/mtx_foo/rw_foo/, you still > have to analyze the code to tell whether or not you can > truly turn them into simultaneous read locks. So what is > the harm in analyzing the code first, and then converting > it to rwlocks IFF it can make use of it? I agree with Daniel here. I also think the following points are relevant: 1) we don't need to rototil the code to s/mtx/rw/ right now. 2) rw locks may not be as effecient as mtx later on and there's no point in doing it right now. -- - Alfred Perlstein From xcllnt at mac.com Sat Jun 7 00:19:26 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Sat Jun 7 00:19:31 2008 Subject: gpt(8) will be removed soon Message-ID: <863BF908-3441-4CEE-8DA0-375965417573@mac.com> All, As previously mentioned, gpt(8) is obsoleted by gpart(8). I'll be removing gpt(8) soon. If you know of a reason not to remove gpt(8), let me know. FYI, -- Marcel Moolenaar xcllnt@mac.com From bugmaster at FreeBSD.org Mon Jun 9 11:06:52 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 9 11:07:01 2008 Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org Message-ID: <200806091106.m59B6pPA070683@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From jeremie at le-hen.org Mon Jun 9 20:13:33 2008 From: jeremie at le-hen.org (Jeremie Le Hen) Date: Mon Jun 9 20:13:36 2008 Subject: Integration of ProPolice in FreeBSD In-Reply-To: <20080423131720.GP92168@obiwan.tataz.chchile.org> References: <20080418132749.GB4840@obiwan.tataz.chchile.org> <200804181945.59189.max@love2party.net> <20080418204738.GE4840@obiwan.tataz.chchile.org> <20080419071400.GP73016@server.vk2pj.dyndns.org> <20080419074921.GI4840@obiwan.tataz.chchile.org> <20080420095911.GT5934@hoeg.nl> <20080423131720.GP92168@obiwan.tataz.chchile.org> Message-ID: <20080609200937.GB72413@obiwan.tataz.chchile.org> Hi Ruslan, all, On Wed, Apr 23, 2008 at 03:17:20PM +0200, Jeremie Le Hen wrote: > Hi Antoine, > > On Fri, Apr 18, 2008 at 04:37:06PM +0200, Antoine Brodin wrote: > > Last time I looked at your patch, there was a problem when using > > -fstack-protector-all instead of -fstack-protector: > > when you compile lib/csu/*, gnu/lib/csu/*, or > > src/lib/libc/sys/stack_protector.c with this flag, there is a kind of > > chicken/egg problem and you end up with an unusable world. > > That said, it would be great to be able to compile world with SSP when > > an option is set in src.conf. > > You were right. I had a chance to test it this weekend. Thank you for > pointing this out. I have had little spare time lately, this is why my followup have taken so long. Since this report from Antoine, my goal has been to be able to use -fstack-protector-all when building world. I hoped it would be quite straightforward, IOW that preventing bootstrap functions from being protected would be enough. Unfortunately, it seems that building libc_pic.a/libc.so with -fstack-protector-all breaks rtld in a very twisted way that I'm unable to untangle for now. Nonetheless, I really want to see this patch hit the tree before 8.x is forked off. I have existed for more than two years and I would like to avoid delaying it futher. So I will go the easy path for now and prevent libc from being built with -fstack-protector-all. Here are what haved changed since the previous patch: - SSP is opt-out except for ia64; this is intended to trigger bugs. However this doesn't mean it will be enabled by default in stable releases. - Thanks to Antoine, SSP related symbols are now compiled without stack protection itself. This prevents a chicken and egg problem. - lib/csu, gnu/lib/csu and libexec/rtld-elf are built without stack protection. I'm looking forward for more review and testing of this patch in order to get it committed soon. Ruslan, would you mind reviewing the change in bsd.own.mk as well? Thank you very much. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > -------------- next part -------------- A non-text attachment was scrubbed... Name: fbsd8-ssp.diff Type: text/x-diff Size: 19938 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20080609/104e70ed/fbsd8-ssp.bin From benno at jeamland.net Fri Jun 13 06:24:36 2008 From: benno at jeamland.net (Benno Rice) Date: Fri Jun 13 06:24:40 2008 Subject: Function to get address within SYS_RES_MEM resource? Message-ID: <2DF4DB2C-D2F4-4558-80B8-C92B3A60865C@jeamland.net> Hi, I'm currently working on porting dmover(9) from NetBSD in order to support the DMA controller on the PXA255. I believe some others are eyeing dmover off to support other similar components. For those that haven't heard of it, dmover is an API for controlling hardware data movers. NetBSD's man page is here: http://netbsd.gw.com/cgi-bin/man-cgi?dmover Currently, dmover supports two types of buffers, in-kernel linear memory ranges and uio buffers. For the task I want to use it for, I need to add a third, which is a static address and width or possibly a SYS_RES_MEM resource with an offset and width. The task in question is copying a packet out of an ethernet controller via PIO. Currently I'm doing this using bus_read_multi_2. In the software dmover backend I could easily implement this using bus_read_multi_* as well. However once I try to offload it to the hardware, I need to be able to get at the physical address that this ends up reading from. My current idea in this regard is to add a new bus_space function along the lines of: void *bus_space_address(bus_space_tag_t, bus_space_handle_t, bus_size_t offset); This function would return a pointer to the relevant _virtual_ address, or NULL if such a thing is not possible. Another option would be: int bus_space_address(bus_space_tag_t, bus_space_handle_t, bus_size_t offset, void **addr); which could return an errno value on failure. This could be shortened to bus_address(struct resource *, bus_size_t offset) in the same way as other bus_space_* functions. I could then turn that into a physical address, either via bus_dma or pmap, and then feed it to the DMAC. I'm also quite willing to be told that there's already an obvious way to do this and I should use that instead. =) -- Benno Rice benno@jeamland.net From marius at alchemy.franken.de Sun Jun 15 16:04:28 2008 From: marius at alchemy.franken.de (Marius Strobl) Date: Sun Jun 15 16:04:31 2008 Subject: Function to get address within SYS_RES_MEM resource? In-Reply-To: <2DF4DB2C-D2F4-4558-80B8-C92B3A60865C@jeamland.net> References: <2DF4DB2C-D2F4-4558-80B8-C92B3A60865C@jeamland.net> Message-ID: <20080615153242.GA14902@alchemy.franken.de> On Fri, Jun 13, 2008 at 04:09:10PM +1000, Benno Rice wrote: > Hi, > > I'm currently working on porting dmover(9) from NetBSD in order to > support the DMA controller on the PXA255. I believe some others are > eyeing dmover off to support other similar components. > > For those that haven't heard of it, dmover is an API for controlling > hardware data movers. NetBSD's man page is here: > > http://netbsd.gw.com/cgi-bin/man-cgi?dmover > > Currently, dmover supports two types of buffers, in-kernel linear > memory ranges and uio buffers. For the task I want to use it for, I > need to add a third, which is a static address and width or possibly a > SYS_RES_MEM resource with an offset and width. The task in question > is copying a packet out of an ethernet controller via PIO. > > Currently I'm doing this using bus_read_multi_2. In the software > dmover backend I could easily implement this using bus_read_multi_* as > well. However once I try to offload it to the hardware, I need to be > able to get at the physical address that this ends up reading from. > > My current idea in this regard is to add a new bus_space function > along the lines of: > > void *bus_space_address(bus_space_tag_t, bus_space_handle_t, > bus_size_t offset); > > This function would return a pointer to the relevant _virtual_ > address, or NULL if such a thing is not possible. Another option > would be: > > int bus_space_address(bus_space_tag_t, bus_space_handle_t, bus_size_t > offset, void **addr); > > which could return an errno value on failure. > > This could be shortened to bus_address(struct resource *, bus_size_t > offset) in the same way as other > bus_space_* functions. > > I could then turn that into a physical address, either via bus_dma or > pmap, and then feed it to the DMAC. > > I'm also quite willing to be told that there's already an obvious way > to do this and I should use that instead. =) > If you can add the offset on your own I think you can use rman_get_virtual(9) for this (which requires f.e. nexus(4) to do a rman_set_virtual(9) though). Marius From bugmaster at FreeBSD.org Mon Jun 16 11:06:51 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 16 11:07:01 2008 Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org Message-ID: <200806161106.m5GB6oWv036652@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems Non-critical problems 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 Jun 16 19:01:31 2008 From: ed at 80386.nl (Ed Schouten) Date: Mon Jun 16 19:01:34 2008 Subject: MPSAFE TTY layer - Testers? Reviews? Message-ID: <20080616185632.GY1176@hoeg.nl> Hello everyone, I hope almost everyone by now knows I'm working on a new MPSAFE TTY layer for our FreeBSD kernel. A lot has happened since I started hacking (14 Feb). Right now my TTY layer is quite functional. There are still some things that are missing, but I think it's very realistic to have this in the base system before 8.0-RELEASE. This is my first public Call for {Testers,Reviews}. To be precise, I'm interested in a couple of things: - "Works for me"'s. The code should be quite robust, but it's possible I missed a thing or two. I would really appreciate it if I could get some other people to test this code. So far, all my applications work like they should, but you can't be too sure. - Feedback on the overall design of the TTY layer - the `high level' stuff. - Feedback on the smaller details of the code. style(9), logical errors, you name it. - Patches for drivers that still need to be ported. There are still some drivers that I haven't ported to the new TTY layer, mainly because I don't own the actual hardware. The patchset I've developed is available at the following location. The file at the bottom is the latest version. It should survive `make universe', except for the sun4v and ia64 architectures. Be sure to boot the new kernel before running `make installworld'. http://www.il.fontys.nl/~ed/projects/mpsafetty/patches/ Below is a list of TODO items: - The sio(4), cy(4), digi(4), ubser(4), uftdi(4), nmdm(4), ng_h4(4), ng_tty(4), sl(4), ppp(4), snp(4), rp(4), rc(4), si(4), umodem(4), dcons(4), IA64 SKI console driver and Sun4V console driver have not been ported yet. ucom(4) also needs to be polished. sio(4) should be replaced by uart(4). Help wanted. - There is no `zombie state' yet; when a disconnect occurs, proper signals are set the session leader, but according to POSIX, we should return 0 byte read()'s then. Support for IXOFF is also missing. - The manual pages are not up-to-date. - PTY's `packet mode' still has to be implemented properly. - The new TTY layer provides a fallback mechanism to allow drivers that use Giant to still work. I had to make some changes to kern_mutex.c, to allow condvar(9) to work with Giant, but this is not ideal. Any ideas here? It would be foolish if I would ask people to review this code, without actually giving a little background: One of the (in my opinion) bad things about the existing TTY code, is that it is not a front-end for device drivers. Many drivers create the TTY device nodes themselves, implement their own cdev routines, etc. My MPSAFE TTY layer only allows device nodes to be created through the TTY layer itself. This means each TTY created by the TTY layer implements a generic behaviour to user processes. Even the PTY driver is no more different than any other driver. All drivers just supply a structure with hooks (struct ttydevsw). Another important structures inside the TTY layer are `ttyinq' and `ttyoutq'. Unlike the existing code, this TTY layer does not use clists to store data. The advantage here is that these queues are better tailored to our requirements. Both queues support unbuffered copying back to userspace, O(1) line termination, etc. I've also rewritten the PTY drivers. We now have two drivers, pts(4) and ptycompat(4). The first driver implements UNIX98 PTY device names (/dev/pts/%u), while ptycompat(4) supports the traditional device naming. The pts(4) driver is compatible with FreeBSD -CURRENT and Linux binaries, while the ptycompat(4) driver should be uses with RELENG_7 and older. PTY's should be removed from the system properly. This means pstat(8) whill now only show PTY's that are actually being used. If there are any more questions, I would be happy to answer them. I think it would be great if we could eventually get this integrated. This will make it possible to make a lot more drivers MPSAFE (i.e. the input layer). Yours, -- 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/20080616/b14e4164/attachment.pgp From ed at 80386.nl Tue Jun 17 16:08:08 2008 From: ed at 80386.nl (Ed Schouten) Date: Tue Jun 17 16:08:23 2008 Subject: MPSAFE TTY layer - Testers? Reviews? In-Reply-To: <20080617154914.GA19455@amp2.iem.pw.edu.pl> References: <20080616185632.GY1176@hoeg.nl> <20080617154914.GA19455@amp2.iem.pw.edu.pl> Message-ID: <20080617160240.GF1176@hoeg.nl> Hello Andrzej, (CC'ing this back to the list, to make sure other people don't experience the same problem) * Andrzej Tobola wrote: > Applield for your patch, rebuild world on -curent amd64, but can't > build kernel: I forgot to tell. You should replace this line: device pty by this: device pts device ptycompat I already changed this in GENERIC, which means it should already build right out of the box. Good luck! -- 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/20080617/1d3c9189/attachment.pgp From helen at nstnetwork.com Wed Jun 18 09:56:57 2008 From: helen at nstnetwork.com (helen@nstnetwork.com) Date: Wed Jun 18 09:57:03 2008 Subject: Sell Cisco Systems equipment items Message-ID: <20080618095826.C45311A86A1@Linux-Mail.com> Hello: We are specialized in new network products, including switch, firewall, router, GBIC,SFP,WIC,cables etc... We provide high quality products and the most reasonable price with professional services to our customers. So if you are interested in any of our products, please contact with me,we will try our best for you,thanks! example of the products: CWDM-SFP-1G 39dB (Ultra long-haul)--1510nm,1530nm,1550nm,1570nm,1590nm,1610nm WS-G5483, WS-G5487, WS-G5484, WS-G5486, GLC-SX-MM, GLC-LH-SM, GLC-ZX-SM, GLC-T, ...... NM-2FE2W-T1, NM-2FE2W-E1, NM-2FE2W-V2, WIC-1T, WIC-2T, WIC-2A/S, WIC-1B/ST, WIC-1ENET, VWIC-1MFT-T1, VWIC-1MFT-E1, VWIC-2MFT-T1, VWIC-2MFT-E1, VWIC-1MFT-G703, VWIC-2MFT-G703, VWIC-1MFT-T1-DI, VWIC-2MFT-T1-DI, NM-1E, NM-4E, ...... WS-C2950-24, WS-C2950T-24, WS-C2950G-24-EI, WS-C2950G-48-EI, ...... CONSOLE CABLE, CAB-STACK-1M/3M, CAB-V35MT, CAB-V35FC, CAB-SS-V.35MT, CAB-SS-V.35FC, CAB-SS-232MT, CAB-SS-232FC, CAB-232MT, CAB-232FC, CAB-SS-X21MT, CAB-SS-X21FC, CAB-X21MT, ...... MEM-npe400-512MB, MEM-3660-128mb, MEM2600-32D, MEM2600-16FS, MEM2600XM-64D, MEM-S1-128MB, MEM-S2-256MB, MEM-S2-512MB, MEM-MSFC-128MB, MEM2801-256D, MEM3800-256D, MEM3800-512, MEM3745-256D, MEM1841-256D, MEM180X-256D, WS-X6K-MSFC2-KIT, .... and so on. กก Regards Helen.Zhou www.nstnetwork.com MSN: Helen@nstnetwork.com Email: Helen@nstnetwork.com AOL helenxuezhou Icq 320-880-606 From bugmaster at FreeBSD.org Mon Jun 23 11:06:51 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 23 11:07:03 2008 Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org Message-ID: <200806231106.m5NB6pqL064902@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From kris at FreeBSD.org Tue Jun 24 22:27:45 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Tue Jun 24 22:27:48 2008 Subject: Integration of ProPolice in FreeBSD In-Reply-To: <20080609200937.GB72413@obiwan.tataz.chchile.org> References: <20080418132749.GB4840@obiwan.tataz.chchile.org> <200804181945.59189.max@love2party.net> <20080418204738.GE4840@obiwan.tataz.chchile.org> <20080419071400.GP73016@server.vk2pj.dyndns.org> <20080419074921.GI4840@obiwan.tataz.chchile.org> <20080420095911.GT5934@hoeg.nl> <20080423131720.GP92168@obiwan.tataz.chchile.org> <20080609200937.GB72413@obiwan.tataz.chchile.org> Message-ID: <486174DE.4080307@FreeBSD.org> Jeremie Le Hen wrote: > I have had little spare time lately, this is why my followup have taken > so long. > > Since this report from Antoine, my goal has been to be able to use > -fstack-protector-all when building world. I hoped it would be quite > straightforward, IOW that preventing bootstrap functions from being > protected would be enough. Unfortunately, it seems that building > libc_pic.a/libc.so with -fstack-protector-all breaks rtld in a very > twisted way that I'm unable to untangle for now. > > Nonetheless, I really want to see this patch hit the tree before 8.x is > forked off. I have existed for more than two years and I would like to > avoid delaying it futher. So I will go the easy path for now and > prevent libc from being built with -fstack-protector-all. > > Here are what haved changed since the previous patch: > - SSP is opt-out except for ia64; this is intended to trigger bugs. > However this doesn't mean it will be enabled by default in stable > releases. > - Thanks to Antoine, SSP related symbols are now compiled without stack > protection itself. This prevents a chicken and egg problem. > - lib/csu, gnu/lib/csu and libexec/rtld-elf are built without stack > protection. > > I'm looking forward for more review and testing of this patch in order > to get it committed soon. > > Ruslan, would you mind reviewing the change in bsd.own.mk as well? > > Thank you very much. > Best regards, > FYI, I did a package build with world built with this patch (but without adding -fstack-protector to CFLAGS). I didnt notice any problems. This makes me slightly suspicious, but another hypothesis is that the patch is in fact safe :-) Kris From kris at FreeBSD.org Tue Jun 24 23:12:41 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Tue Jun 24 23:12:45 2008 Subject: Integration of ProPolice in FreeBSD In-Reply-To: <486174DE.4080307@FreeBSD.org> References: <20080418132749.GB4840@obiwan.tataz.chchile.org> <200804181945.59189.max@love2party.net> <20080418204738.GE4840@obiwan.tataz.chchile.org> <20080419071400.GP73016@server.vk2pj.dyndns.org> <20080419074921.GI4840@obiwan.tataz.chchile.org> <20080420095911.GT5934@hoeg.nl> <20080423131720.GP92168@obiwan.tataz.chchile.org> <20080609200937.GB72413@obiwan.tataz.chchile.org> <486174DE.4080307@FreeBSD.org> Message-ID: <48617F66.6050607@FreeBSD.org> Kris Kennaway wrote: > FYI, I did a package build with world built with this patch (but without > adding -fstack-protector to CFLAGS). I didnt notice any problems. This > makes me slightly suspicious, but another hypothesis is that the patch > is in fact safe :-) I'm running a build with CFLAGS += -fstack-protector now...just to see how much chaos will ensue :) Kris From jeremie at le-hen.org Wed Jun 25 09:31:10 2008 From: jeremie at le-hen.org (Jeremie Le Hen) Date: Wed Jun 25 09:31:15 2008 Subject: Integration of ProPolice in FreeBSD In-Reply-To: <48617F66.6050607@FreeBSD.org> References: <200804181945.59189.max@love2party.net> <20080418204738.GE4840@obiwan.tataz.chchile.org> <20080419071400.GP73016@server.vk2pj.dyndns.org> <20080419074921.GI4840@obiwan.tataz.chchile.org> <20080420095911.GT5934@hoeg.nl> <20080423131720.GP92168@obiwan.tataz.chchile.org> <20080609200937.GB72413@obiwan.tataz.chchile.org> <486174DE.4080307@FreeBSD.org> <48617F66.6050607@FreeBSD.org> Message-ID: <20080625092640.GC15815@obiwan.tataz.chchile.org> Hi Kris, Thank you for testing this :). On Wed, Jun 25, 2008 at 01:12:38AM +0200, Kris Kennaway wrote: > Kris Kennaway wrote: > > FYI, I did a package build with world built with this patch (but without > > adding -fstack-protector to CFLAGS). I didnt notice any problems. This > > makes me slightly suspicious, but another hypothesis is that the patch is > > in fact safe :-) > > I'm running a build with CFLAGS += -fstack-protector now...just to see how > much chaos will ensue :) All ports on my laptop are compiled with it. Only a few ones broke during build: lang/gcc41 lang/gcc42 (gcc4x should break too) emulators/qemu net/etherboot Firefox, Gnome, X.org, and everything else seems to not only compile but also work correctly. There may be little noise on freebsd-ports@ once the ports bits will have been provided, because Propolice may put forth a few bugs involving stack based buffers. In this case, the program is killed with SIGABRT and message "stack overflow detected; terminated" is issued to syslog. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From kris at FreeBSD.org Wed Jun 25 12:01:57 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Wed Jun 25 12:02:04 2008 Subject: Integration of ProPolice in FreeBSD In-Reply-To: <20080625092640.GC15815@obiwan.tataz.chchile.org> References: <200804181945.59189.max@love2party.net> <20080418204738.GE4840@obiwan.tataz.chchile.org> <20080419071400.GP73016@server.vk2pj.dyndns.org> <20080419074921.GI4840@obiwan.tataz.chchile.org> <20080420095911.GT5934@hoeg.nl> <20080423131720.GP92168@obiwan.tataz.chchile.org> <20080609200937.GB72413@obiwan.tataz.chchile.org> <486174DE.4080307@FreeBSD.org> <48617F66.6050607@FreeBSD.org> <20080625092640.GC15815@obiwan.tataz.chchile.org> Message-ID: <486233B1.2040006@FreeBSD.org> Jeremie Le Hen wrote: > Hi Kris, > > Thank you for testing this :). > > On Wed, Jun 25, 2008 at 01:12:38AM +0200, Kris Kennaway wrote: >> Kris Kennaway wrote: >>> FYI, I did a package build with world built with this patch (but without >>> adding -fstack-protector to CFLAGS). I didnt notice any problems. This >>> makes me slightly suspicious, but another hypothesis is that the patch is >>> in fact safe :-) >> I'm running a build with CFLAGS += -fstack-protector now...just to see how >> much chaos will ensue :) > > All ports on my laptop are compiled with it. Only a few ones broke > during build: > lang/gcc41 > lang/gcc42 (gcc4x should break too) > emulators/qemu > net/etherboot There are some others so far: Everything gcc-derived: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.8-exp.2008062315/g95-0.91.20070129.log http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.8-exp.2008062315/gcc-ooo-3.4.1_3.log http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.8-exp.2008062315/gcc-3.4.6_3,1.log http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.8-exp.2008062315/mingw32-gcc-4.2.1,1.log http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.8-exp.2008062315/gpc-20060325_1.log ... build error: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.8-exp.2008062315/ruby18-eet-0.1.4.log http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.8-exp.2008062315/ruby18-evas-20080302.log segfaults, not aborts: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.8-exp.2008062315/zh-mplayer-fonts-1.0_1.log runtime error: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.8-exp.2008062315/quranref-1.01_1.log linker failure: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.8-exp.2008062315/emacs.app-9.0_3.log sigbus: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.8-exp.2008062315/ikiwiki-2.48_1.log http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.8-exp.2008062315/drscheme-370_2.log abort due to stack protector: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.8-exp.2008062315/vips-7.12.4_3.log Kris From rwatson at FreeBSD.org Thu Jun 26 12:13:44 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Thu Jun 26 12:13:49 2008 Subject: Integration of ProPolice in FreeBSD In-Reply-To: <20080625092640.GC15815@obiwan.tataz.chchile.org> References: <200804181945.59189.max@love2party.net> <20080418204738.GE4840@obiwan.tataz.chchile.org> <20080419071400.GP73016@server.vk2pj.dyndns.org> <20080419074921.GI4840@obiwan.tataz.chchile.org> <20080420095911.GT5934@hoeg.nl> <20080423131720.GP92168@obiwan.tataz.chchile.org> <20080609200937.GB72413@obiwan.tataz.chchile.org> <486174DE.4080307@FreeBSD.org> <48617F66.6050607@FreeBSD.org> <20080625092640.GC15815@obiwan.tataz.chchile.org> Message-ID: <20080626125416.R96707@fledge.watson.org> On Wed, 25 Jun 2008, Jeremie Le Hen wrote: >> I'm running a build with CFLAGS += -fstack-protector now...just to see how >> much chaos will ensue :) > > All ports on my laptop are compiled with it. Only a few ones broke > during build: > lang/gcc41 > lang/gcc42 (gcc4x should break too) > emulators/qemu > net/etherboot > > Firefox, Gnome, X.org, and everything else seems to not only compile but > also work correctly. > > There may be little noise on freebsd-ports@ once the ports bits will have > been provided, because Propolice may put forth a few bugs involving stack > based buffers. In this case, the program is killed with SIGABRT and message > "stack overflow detected; terminated" is issued to syslog. I'd guess that this is rather well-trodden ground by other projects, since most operating systems ship with stack protection enabled by default these days. Our dubious advantage is that other people have probably found many of the problems in third-party applications themselves at this point :-). Robert N M Watson Computer Laboratory University of Cambridge From milo at cyberlifelabs.com Fri Jun 27 03:05:29 2008 From: milo at cyberlifelabs.com (Milo Hyson) Date: Fri Jun 27 03:05:35 2008 Subject: Curious about SCM choice Message-ID: I apologize in advance if I have the wrong list for this, but it didn't really look like anywhere else was more appropriate. I'm curious about the reasons for FreeBSD adopting Subversion over the other candidate systems. I've read the pages discussing the pros and cons, but haven't found anything discussing the ultimate deciding factors. I ask not because I disagree with the decision, but because my company is currently facing a similar situation. We currently use Subversion but there is some interest in other tools. Understanding what "tipped the scales" as it were could prove valuable in our own decision making. Thanks. :) -- Milo Hyson Chief Scientist CyberLife Labs From dougb at FreeBSD.org Fri Jun 27 05:56:02 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Fri Jun 27 05:56:05 2008 Subject: Curious about SCM choice In-Reply-To: References: Message-ID: <48647AAD.5040909@FreeBSD.org> Milo Hyson wrote: > I apologize in advance if I have the wrong list for this, but it didn't > really look like anywhere else was more appropriate. > > I'm curious about the reasons for FreeBSD adopting Subversion over the > other candidate systems. I've read the pages discussing the pros and > cons, but haven't found anything discussing the ultimate deciding > factors. I ask not because I disagree with the decision, but because my > company is currently facing a similar situation. We currently use > Subversion but there is some interest in other tools. Understanding what > "tipped the scales" as it were could prove valuable in our own decision > making. I am NOT the expert on this, but I'll try to give you something to chew on (in no particular order) until someone smarter speaks up. :) 1. It's better to start collecting meta-data (change sets, merge info, etc.) sooner than later. 2. Of the systems available at this point, subversion is the easiest to export _from_. Which is to say, if we decide to use something else later on down the road it will be easier to migrate the repository from subversion to $NEWTHING. It's also possible to use frontends like git and Hg with subversion now, so people who really like those systems can have a comfortable environment to work in. 3. Subversion is close enough to cvs to give old farts like me less stress over the change. 4. Most of the other VCS' focus heavily on the idea of "distributed" operation, which doesn't really fit our development model. hth, Doug -- This .signature sanitized for your protection From jhb at freebsd.org Fri Jun 27 06:15:23 2008 From: jhb at freebsd.org (John Baldwin) Date: Fri Jun 27 06:15:26 2008 Subject: Curious about SCM choice In-Reply-To: <48647AAD.5040909@FreeBSD.org> References: <48647AAD.5040909@FreeBSD.org> Message-ID: <200806270214.46861.jhb@freebsd.org> On Friday 27 June 2008 01:29:17 am Doug Barton wrote: > Milo Hyson wrote: > > I apologize in advance if I have the wrong list for this, but it didn't > > really look like anywhere else was more appropriate. > > > > I'm curious about the reasons for FreeBSD adopting Subversion over the > > other candidate systems. I've read the pages discussing the pros and > > cons, but haven't found anything discussing the ultimate deciding > > factors. I ask not because I disagree with the decision, but because my > > company is currently facing a similar situation. We currently use > > Subversion but there is some interest in other tools. Understanding what > > "tipped the scales" as it were could prove valuable in our own decision > > making. > > I am NOT the expert on this, but I'll try to give you something to chew > on (in no particular order) until someone smarter speaks up. :) > > 1. It's better to start collecting meta-data (change sets, merge info, > etc.) sooner than later. > 2. Of the systems available at this point, subversion is the easiest to > export _from_. Which is to say, if we decide to use something else later > on down the road it will be easier to migrate the repository from > subversion to $NEWTHING. It's also possible to use frontends like git > and Hg with subversion now, so people who really like those systems can > have a comfortable environment to work in. > 3. Subversion is close enough to cvs to give old farts like me less > stress over the change. > 4. Most of the other VCS' focus heavily on the idea of "distributed" > operation, which doesn't really fit our development model. Another factor is that in SVN keyword expansion ($Id$ and the like) still uses monotonically increasing numbers. Thus, you can run 'ident' on a file and you can tell if it is newer or older than another version of the file. AFAIK, git and hg both use hashes to represent different versions of a file, and you can't just look at two different MD5 hashes and know which one is newer or older. You have to actually have a repository lying around that you can connect to and query. This is more an issue of user ease-of-use than developer ease of use. Think of the case of security advisories (this was fixed in version X on the RELENG_foo branch). It's easier to see if your latest build has version X when you have version numbers than if you deal with hashes. Another requirement that FreeBSD has is the ability to be able to obliterate portions of the tree (e.g. someone accidentally commits something that they shouldn't have due to a misunderstanding, etc.). CVS is the easiest here as you can just rm the foo,v files and cvsup will cope. :) SVN is somewhat doable (my understanding is that one does a dump piped through a filter to remove the undesirables piped to restore). I'm not sure what the level of obliterate support is in hg/git. I know at one point neither supported it, but I thought I had heard that at least one was working on adding it. git is also designed to handle smaller repositories, so the preferred model for using git on a large codebase is to split your code base up into many smaller repositories. At least that is my understanding. For FreeBSD that didn't really fit our development model as one of our traditional strengths/differentiators has been a unified tree that contains a full OS. -- John Baldwin From milo at cyberlifelabs.com Fri Jun 27 07:12:51 2008 From: milo at cyberlifelabs.com (Milo Hyson) Date: Fri Jun 27 07:12:56 2008 Subject: Curious about SCM choice In-Reply-To: <48647AAD.5040909@FreeBSD.org> References: <48647AAD.5040909@FreeBSD.org> Message-ID: <7D28014A-C3FB-4944-95FC-15F299F9AF37@cyberlifelabs.com> On Jun 26, 2008, at 22:29, Doug Barton wrote: > 1. It's better to start collecting meta-data (change sets, merge > info, etc.) sooner than later. May I assume by "collecting" you mean gathering together in a location controlled by the FreeBSD team and made available to others? This was an argument made here in favor of centralized systems like Subversion. If someone is doing any significant work, we want it within the project so others can see and use it. > 4. Most of the other VCS' focus heavily on the idea of "distributed" > operation, which doesn't really fit our development model. The only real benefits I saw in distributed systems were private branching and offline work. The former seems like it could be achieved in Subversion by creating semi-private user directories like FreeBSD does. As for the latter, while it's sometimes unavoidable (e.g. working on an airplane) isn't something we really want to encourage. -- Milo Hyson Chief Scientist CyberLife Labs From des at des.no Fri Jun 27 15:46:53 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Fri Jun 27 15:46:57 2008 Subject: Curious about SCM choice In-Reply-To: <7D28014A-C3FB-4944-95FC-15F299F9AF37@cyberlifelabs.com> (Milo Hyson's message of "Fri\, 27 Jun 2008 00\:12\:50 -0700") References: <48647AAD.5040909@FreeBSD.org> <7D28014A-C3FB-4944-95FC-15F299F9AF37@cyberlifelabs.com> Message-ID: <86ej6iyjz3.fsf@ds4.des.no> Milo Hyson writes: > Doug Barton wrote: > > 1. It's better to start collecting meta-data (change sets, merge > > info, etc.) sooner than later. > May I assume by "collecting" you mean gathering together in a location > controlled by the FreeBSD team and made available to others? Subversion stores more information about each commit than CVS does, especially when it comes to moving, copying, branching and merging files. This information is called metadata. By switching to Subversion, we start storing (rather than discarding) this information, which will make it easier to switch to another system later. DES -- Dag-Erling Sm?rgrav - des@des.no From gordon at tetlows.org Fri Jun 27 18:04:08 2008 From: gordon at tetlows.org (Gordon Tetlow) Date: Fri Jun 27 18:04:12 2008 Subject: Curious about SCM choice In-Reply-To: References: Message-ID: <4e571dd70806271037j59faed19y8d3e29423c9d8a2@mail.gmail.com> On Thu, Jun 26, 2008 at 7:55 PM, Milo Hyson wrote: > I apologize in advance if I have the wrong list for this, but it didn't > really look like anywhere else was more appropriate. > > I'm curious about the reasons for FreeBSD adopting Subversion over the > other candidate systems. I've read the pages discussing the pros and cons, > but haven't found anything discussing the ultimate deciding factors. I ask > not because I disagree with the decision, but because my company is > currently facing a similar situation. We currently use Subversion but there > is some interest in other tools. Understanding what "tipped the scales" as > it were could prove valuable in our own decision making. > As an SCM expert at my place of employment, it really does come down to a couple of simple decisions. The biggest one for a company is: Do you want a centralized or distributed model for your development model? CVS, SVN, and Perforce are all centralized repositories (Perforce even moreso that the others). Hg, git, and bzr are all decentralized and distributed models. Moving to SVN makes a lot of sense for the FreeBSD project both as a stepping stone (it's better than CVS and retains more information), works well with our existing infrastructure (we can export things back to CVS relatively easily to support CVSup since the usage model between them is very similar), and works well with our existing development model (one central repository that everyone talks to). These are the reasons it makes sense for the FreeBSD project, you'll have to identify the reasons that make sense for your company. -gordon From milo at cyberlifelabs.com Sat Jun 28 01:26:55 2008 From: milo at cyberlifelabs.com (Milo Hyson) Date: Sat Jun 28 01:27:00 2008 Subject: Curious about SCM choice In-Reply-To: <4e571dd70806271037j59faed19y8d3e29423c9d8a2@mail.gmail.com> References: <4e571dd70806271037j59faed19y8d3e29423c9d8a2@mail.gmail.com> Message-ID: <1E7FB809-CFBE-4ED6-9F32-97C90359BBF9@cyberlifelabs.com> On Jun 27, 2008, at 10:37, Gordon Tetlow wrote: > Do you want a centralized or distributed model for your development > model? CVS, SVN, and Perforce are all centralized repositories > (Perforce even moreso that the others). Hg, git, and bzr are all > decentralized and distributed models. ... > Moving to SVN makes a lot of sense for the FreeBSD project ... works > well with our existing development model (one central repository > that everyone talks to). Can not the "decentralized" systems like Mercurial and GIT be used in a centralized fashion? Our internal experiments certainly show them to be every bit as capable as Subversion in this regard. Has your experience been different? -- Milo Hyson Chief Scientist CyberLife Labs From brix at FreeBSD.org Sat Jun 28 07:53:37 2008 From: brix at FreeBSD.org (Henrik Brix Andersen) Date: Sat Jun 28 07:53:45 2008 Subject: Curious about SCM choice In-Reply-To: <7D28014A-C3FB-4944-95FC-15F299F9AF37@cyberlifelabs.com> References: <48647AAD.5040909@FreeBSD.org> <7D28014A-C3FB-4944-95FC-15F299F9AF37@cyberlifelabs.com> Message-ID: <20080628073544.GA45690@tirith.brixandersen.dk> On Fri, Jun 27, 2008 at 12:12:50AM -0700, Milo Hyson wrote: > The only real benefits I saw in distributed systems were private branching > and offline work. The former seems like it could be achieved in Subversion > by creating semi-private user directories like FreeBSD does. As for the > latter, while it's sometimes unavoidable (e.g. working on an airplane) > isn't something we really want to encourage. The latter (offline work) can also be done with SVN by using the SVK [1] frontend. Brix [1]: http://svk.bestpractical.com/view/HomePage -- Henrik Brix Andersen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 217 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20080628/6d671b6a/attachment.pgp From brix at FreeBSD.org Sat Jun 28 07:53:37 2008 From: brix at FreeBSD.org (Henrik Brix Andersen) Date: Sat Jun 28 07:53:46 2008 Subject: Curious about SCM choice In-Reply-To: <1E7FB809-CFBE-4ED6-9F32-97C90359BBF9@cyberlifelabs.com> References: <4e571dd70806271037j59faed19y8d3e29423c9d8a2@mail.gmail.com> <1E7FB809-CFBE-4ED6-9F32-97C90359BBF9@cyberlifelabs.com> Message-ID: <20080628073807.GB45690@tirith.brixandersen.dk> On Fri, Jun 27, 2008 at 06:26:54PM -0700, Milo Hyson wrote: > Can not the "decentralized" systems like Mercurial and GIT be used in a > centralized fashion? Our internal experiments certainly show them to be > every bit as capable as Subversion in this regard. Has your experience been > different? They _can_ be used in centralized fashion, but they do not enforce it. Subversion enforces a centralized development model. Brix -- Henrik Brix Andersen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 217 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20080628/e13b61b7/attachment.pgp From rwatson at FreeBSD.org Sat Jun 28 08:05:47 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Sat Jun 28 08:05:51 2008 Subject: Curious about SCM choice In-Reply-To: <20080628073807.GB45690@tirith.brixandersen.dk> References: <4e571dd70806271037j59faed19y8d3e29423c9d8a2@mail.gmail.com> <1E7FB809-CFBE-4ED6-9F32-97C90359BBF9@cyberlifelabs.com> <20080628073807.GB45690@tirith.brixandersen.dk> Message-ID: <20080628085440.D18482@fledge.watson.org> On Sat, 28 Jun 2008, Henrik Brix Andersen wrote: > On Fri, Jun 27, 2008 at 06:26:54PM -0700, Milo Hyson wrote: >> Can not the "decentralized" systems like Mercurial and GIT be used in a >> centralized fashion? Our internal experiments certainly show them to be >> every bit as capable as Subversion in this regard. Has your experience been >> different? > > They _can_ be used in centralized fashion, but they do not enforce it. > Subversion enforces a centralized development model. Well, tools like svk bring the benefits of decentralized development to svn, and many decentralized tools can easily piggy-back on the changeset stream for svn, so I'm not sure I'd use the word "enforce". I think the driving factors really come down to some more practical concerns: - The migration to svn from cvs is an incremental step, which means that the conversion is (was) less likely to seriously interrupt development. - The import and export from cvs is well-understood and well-honed; Peter still had to do a month of work to get it to import, and that helps capture what a massive task even that was. Export is really important to, as we will continue to support cvsup of a consistently structured repository for the forseeable future using CVS and cvsup. - Certain key features are precluded *by design* in many of the decentralized tools. In particular, the use of cryptographic hashes to over changesets to construct version identifiers means that the tools would have to be rather seriously modified to support obliteration, and we consider obliteration a functional requirement. It's not as easy in svn as in cvs, but it is possible, and that is key. We'd love to see the DVCS systems that currently prevent obliterate grow some sort of support for it, and I can't imagine that we are alone in this requirement. - We make extensive use of $FreeBSD$ version identifiers when debugging user problems, and cryptographic hash values used by some systems for version numbers don't meet our requirements. For example, access to a repository is required to answer the question "Do you have foo.h revision X or greater". - There was a stron desire to support partial check-outs of our tree without subdividing the tree, which would lose the benefit of atomic changesets, not to mention our generally unified approach to build and revision control. Interestingly, many of the DCVS tools don't allow you to say "just check out the kernel" without organizing repositories around "the kernel" as an administrative boundary. There's a pretty long thread discussing whether git could be used by the KDE folks for this reason, who also have a very large repository. The conclusion appeared to be that they'd need to break it into many smaller repositories. There are other similar scalability concerns with several other pieces of DCVS software. I think it's also worth pointing out that the SVN and SVK folk have been incredibly helpful during the migration; and, of course, it shouldn't be ignored that SVN provides many of the features we *do* require, especially with 1.5, and does them efficiently and well. SVN also makes it easier for developers or third parties who *do* want to use DCVS to do so: instead of exporting CVS meta-data, we're now exporting a consistent changeset stream with merging meta-data, etc, which is a much better thing to import into a DCVS. As the transition was a complex and very long-running project (and still is running!), there's a lot more to it than can be easily captured in a bullet list, and I'm certain I've missed at least a few interesting points. Perhaps Peter will chime in and mention some more :-). Robert N M Watson Computer Laboratory University of Cambridge From des at des.no Sat Jun 28 16:11:37 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Sat Jun 28 16:11:41 2008 Subject: Curious about SCM choice In-Reply-To: <4e571dd70806271037j59faed19y8d3e29423c9d8a2@mail.gmail.com> (Gordon Tetlow's message of "Fri\, 27 Jun 2008 10\:37\:55 -0700") References: <4e571dd70806271037j59faed19y8d3e29423c9d8a2@mail.gmail.com> Message-ID: <86tzfdwnd4.fsf@ds4.des.no> "Gordon Tetlow" writes: > As an SCM expert at my place of employment, [...] As an SCM expert, you should know that neither CVS not Subversion are SCM tools. Neither are any of the other systems you mention, except perhaps, at a stretch, Perforce. They are version (or revision) control systems. DES -- Dag-Erling Sm?rgrav - des@des.no From rcoleman at criticalmagic.com Sun Jun 29 03:55:51 2008 From: rcoleman at criticalmagic.com (Richard Coleman) Date: Sun Jun 29 03:55:55 2008 Subject: Curious about SCM choice In-Reply-To: <7D28014A-C3FB-4944-95FC-15F299F9AF37@cyberlifelabs.com> References: <48647AAD.5040909@FreeBSD.org> <7D28014A-C3FB-4944-95FC-15F299F9AF37@cyberlifelabs.com> Message-ID: <486702D9.2060204@criticalmagic.com> Milo Hyson wrote: > The only real benefits I saw in distributed systems were private > branching and offline work. The former seems like it could be achieved > in Subversion by creating semi-private user directories like FreeBSD > does. As for the latter, while it's sometimes unavoidable (e.g. working > on an airplane) isn't something we really want to encourage. First of all, I think most of the version control systems had progressed to the point where virtually anything was an improvement over CVS. So I was glad to see FreeBSD make the jump and convert to subversion. It's a good system. So I have no axe to grind there. The only thing really lacking is a good way to handle local code. The old method of using CVS_LOCAL_BRANCH_NUM is very fragile. How is everyone managing their local code now with the conversion to subversion? This is the only place I miss using hg or bzr. Richard Coleman rcoleman@criticalmagic.com From imp at bsdimp.com Sun Jun 29 05:53:57 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Sun Jun 29 05:54:00 2008 Subject: Curious about SCM choice In-Reply-To: <20080628073807.GB45690@tirith.brixandersen.dk> References: <4e571dd70806271037j59faed19y8d3e29423c9d8a2@mail.gmail.com> <1E7FB809-CFBE-4ED6-9F32-97C90359BBF9@cyberlifelabs.com> <20080628073807.GB45690@tirith.brixandersen.dk> Message-ID: <20080628.235225.-233676791.imp@bsdimp.com> In message: <20080628073807.GB45690@tirith.brixandersen.dk> Henrik Brix Andersen writes: : On Fri, Jun 27, 2008 at 06:26:54PM -0700, Milo Hyson wrote: : > Can not the "decentralized" systems like Mercurial and GIT be used in a : > centralized fashion? Our internal experiments certainly show them to be : > every bit as capable as Subversion in this regard. Has your experience been : > different? : : They _can_ be used in centralized fashion, but they do not enforce : it. Subversion enforces a centralized development model. Well, hg requires one merge to the tip before committing to the tip, which has its own set of problems when used in a centralized manner. Warner From adrian at freebsd.org Sun Jun 29 07:46:36 2008 From: adrian at freebsd.org (Adrian Chadd) Date: Sun Jun 29 07:46:39 2008 Subject: Curious about SCM choice In-Reply-To: <486702D9.2060204@criticalmagic.com> References: <48647AAD.5040909@FreeBSD.org> <7D28014A-C3FB-4944-95FC-15F299F9AF37@cyberlifelabs.com> <486702D9.2060204@criticalmagic.com> Message-ID: 2008/6/29 Richard Coleman : > The only thing really lacking is a good way to handle local code. The old > method of using CVS_LOCAL_BRANCH_NUM is very fragile. How is everyone > managing their local code now with the conversion to subversion? This is > the only place I miss using hg or bzr. svk? I've heard it gets confused by the freebsd svn repo if you use a partial tree so I haven't tried yet but I've been tinkering with it for another project. It seems to work alright. Adrian From rwatson at FreeBSD.org Sun Jun 29 17:02:50 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Jun 29 17:02:54 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <20080524111715.T64552@fledge.watson.org> References: <20080524111715.T64552@fledge.watson.org> Message-ID: <20080629180126.F90836@fledge.watson.org> On Sat, 24 May 2008, Robert Watson wrote: > Just as a reminder, we've just about reached the one month date before > IFF_NEEDSGIANT drivers are disabled in the build. You can find a > description of the general problem and list of specific drivers below. > > As USB work is on-going, I will *not* disable the USB drivers at this time, > but all other drivers in the list below will be disabled on 26 June. They > will remain in the tree, easily accessible for patch distribution and > re-enabling, until October, when any remaining non-MPSAFE drivers will be > deleted in 8.x. FreeBSD 8.0 will not ship with compatibility shims to > support non-MPSAFE network device drivers. An FYI on the state of things here: in the last month, John has updated a number of device drivers to be MPSAFE, and the USB work remains in-flight. I'm holding fire a bit on disabling IFF_NEEDSGIANT while things settle and I catch up on driver state, and will likely send out an update next week regarding which device drivers remain on the kill list, and generally what the status of this project is. Robert N M Watson Computer Laboratory University of Cambridge > > Robert N M Watson Computer Laboratory University of Cambridge > > ---------- Forwarded message ---------- > Date: Sun, 3 Feb 2008 20:59:05 +0000 (GMT) > From: Robert Watson > To: arch@FreeBSD.org > Subject: 8.0 network stack MPsafety goals (fwd) > > > Only a few days after predicted, this is a reminder that IFF_NEEDSGIANT > network drivers are going to stop working in the forseeable future. Please > review the attached driver list, and if you depend on or care about a > Giant-dependent device driver, take action to make sure it doesn't remain on > the list in a month's time! > > (As far as I'm aware, the list has not changed since my December posting.) > > Robert N M Watson > Computer Laboratory > University of Cambridge > > ---------- Forwarded message ---------- > Date: Mon, 24 Dec 2007 10:43:28 +0000 (GMT) > From: Robert Watson > To: arch@FreeBSD.org > Subject: 8.0 network stack MPsafety goals > > > Dear all: > > With the 7.0 release around the corner, many developers are starting to think > about (and in quite a few cases, work on) their goals for 8.0. One of our > on-going kernel projects has been the elimination of the Giant lock, and that > project has transformed into one of optimizating behavior on increasing > numbers of processors. > > In 7.0, despite the noteworth accomplishment of eliminating debug.mpsasfenet > and conditional network stack Gian acquisition, we were unable to fully > eliminate the IFF_NEEDSGIANT flag, which controls the conditional acquisition > of the Giant lock around non-MPSAFE network device drivers. Primarily these > drivers are aging ISA network device drivers, although there are some > exceptions, such as the USB stack. > > This e-mail proposes the elimination of the IFF_NEEDSGIANT flag and > associated infrastructure in FreeBSD 8.0, meaning that all network device > drivers must be able to operate without the Giant lock (largely the case > already). Remaining drivers using the IFF_NEEDSGIANT flag must either be > updated, or less ideally, removed. I propose the following schedule: > > Date Goals > ---- ----- > 26 Dec 2007 Post proposed schedule for flag and infrastructure removal > Post affected driver list > > 26 Jan 2008 Repost proposed schedule for flag and infrastructure removal > Post updated affected driver list > > 26 Feb 2008 Adjust boot-time printf for affect drivers to generate a loud > warning. > Post updated affected driver list > > 26 May 2008 Post HEADS UP of impending driver disabling > Post updated affected driver list > > 26 Jun 2008 Disable build of all drivers requiring IFF_NEEDSGIANT > Post updated affected driver list > > 26 Sep 2008 Post HEADS up of impending driver removal > Post updated affected driver list > > 26 Oct 2008 Delete source of all drivers requiring IFF_NEEDSGIANT > Remove flag and infrastructure > > Here is a list of potentially affected drivers: > > Name Bus Man page description > --- --- -------------------- > ar ISA/PCI synchronous Digi/Arnet device driver > arl ISA Aironet Arlan 655 wireless network adapter driver > awi PCCARD AMD PCnetMobile IEEE 802.11 PCMCIA wireless network > driver > axe USB ASIX Electronics AX88172 USB Ethernet driver > cdce USB USB Communication Device Class Ethernet driver > cnw PCCARD Netwave AirSurfer wireless network driver > cs ISA/PCCARD Ethernet device driver > cue USB CATC USB-EL1210A USB Ethernet driver > ex ISA/PCCARD Ethernet device driver for the Intel EtherExpress > Pro/10 and Pro/10+ > fe CBUS/ISA/PCCARD Fujitsu MB86960A/MB86965A based Ethernet adapters > ic I2C I2C bus system > ie ISA Ethernet device driver > kue USB Kawasaki LSI KL5KUSB101B USB Ethernet driver > oltr ISA/PCI Olicom Token Ring device driver > plip PPBUS printer port Internet Protocol driver > ppp TTY point to point protocol network interface > ray PCCARD Raytheon Raylink/Webgear Aviator PCCard driver > rue USB RealTek RTL8150 USB to Fast Ethernet controller > driver > rum USB Ralink Technology USB IEEE 802.11a/b/g wireless > network device > sbni ISA/PCI Granch SBNI12 leased line modem driver > sbsh PCI Granch SBNI16 SHDSL modem device driver > sl TTY slip network interface > snc ISA/PCCARD National Semiconductor DP8393X SONIC Ethernet adapter > driver > sr ISA/PCI synchronous RISCom/N2 / WANic 400/405 device driver > udav USB Davicom DM9601 USB Ethernet driver > ural USB Ralink Technology RT2500USB IEEE 802.11 driver > xe PCCARD Xircom PCMCIA Ethernet device driver > zyd USB ZyDAS ZD1211/ZD1211B USB IEEE 802.11b/g wireless > network device > > In some cases, the requirement for Giant is a property of a subsystem the > driver depends on as the driver itself; for example, the tty subsystem for > SLIP and PPP, and the USB subsystem for a number of USB ethernet and wireless > drivers. With most of a year before to go on the proposed schedule, my hope > is that we will have lots of time to address these issues, but wanted to get > a roadmap out from a network protocol stack architecture perspective so that > device driver and subsystem authors could have a schedule in mind. > > FYI, the following drivers also reference IFF_NEEDSGIANT, but only in order > to provide their own conditional MPSAFEty, which can be removed without > affecting device driver functionality (I believe): > > Name Bus Man page description > --- --- -------------------- > ce PCI driver for synchronous Cronyx Tau-PCI/32 WAN adapters > cp PCI driver for synchronous Cronyx Tau-PCI WAN adapters > ctau ISA driver for synchronous Cronyx Tau WAN adapters > cx ISA driver for synchronous/asynchronous Cronyx Sigma WAN > adapters > > Developers and users of the above drivers are heavily encouraged to update > the drivers to remove dependence on Giant, and/or make other contingency > plans. > > Robert N M Watson > Computer Laboratory > University of Cambridge > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From gordon at tetlows.org Mon Jun 30 04:50:05 2008 From: gordon at tetlows.org (Gordon Tetlow) Date: Mon Jun 30 04:50:08 2008 Subject: Curious about SCM choice In-Reply-To: <86tzfdwnd4.fsf@ds4.des.no> References: <4e571dd70806271037j59faed19y8d3e29423c9d8a2@mail.gmail.com> <86tzfdwnd4.fsf@ds4.des.no> Message-ID: <4e571dd70806292150vd6f47e1y430206f5a4a3d963@mail.gmail.com> On Sat, Jun 28, 2008 at 9:11 AM, Dag-Erling Sm?rgrav wrote: > "Gordon Tetlow" writes: > > As an SCM expert at my place of employment, [...] > > As an SCM expert, you should know that neither CVS not Subversion are > SCM tools. Neither are any of the other systems you mention, except > perhaps, at a stretch, Perforce. They are version (or revision) control > systems. Ah, a problem with that acronym is it has 2 different meanings (which I think we were using different ones). I was meaning source code management, while I think you were meaning software configuration management? -gordon From des at des.no Mon Jun 30 07:42:47 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Jun 30 07:42:52 2008 Subject: Curious about SCM choice In-Reply-To: <4e571dd70806292150vd6f47e1y430206f5a4a3d963@mail.gmail.com> (Gordon Tetlow's message of "Sun\, 29 Jun 2008 21\:50\:04 -0700") References: <4e571dd70806271037j59faed19y8d3e29423c9d8a2@mail.gmail.com> <86tzfdwnd4.fsf@ds4.des.no> <4e571dd70806292150vd6f47e1y430206f5a4a3d963@mail.gmail.com> Message-ID: <86iqvrqsgb.fsf@ds4.des.no> "Gordon Tetlow" writes: > Dag-Erling Sm?rgrav writes: > > As an SCM expert, you should know that neither CVS not Subversion > > are SCM tools. Neither are any of the other systems you mention, > > except perhaps, at a stretch, Perforce. They are version (or > > revision) control systems. > Ah, a problem with that acronym is it has 2 different meanings (which I > think we were using different ones). I was meaning source code management, > while I think you were meaning software configuration management? I've never heard of "source code managmenet", actually, but yes. DES -- Dag-Erling Sm?rgrav - des@des.no From rwatson at FreeBSD.org Mon Jun 30 08:27:12 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Jun 30 08:27:23 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <20080629180126.F90836@fledge.watson.org> References: <20080524111715.T64552@fledge.watson.org> <20080629180126.F90836@fledge.watson.org> Message-ID: <20080630091033.P3968@fledge.watson.org> On Sun, 29 Jun 2008, Robert Watson wrote: > An FYI on the state of things here: in the last month, John has updated a > number of device drivers to be MPSAFE, and the USB work remains in-flight. > I'm holding fire a bit on disabling IFF_NEEDSGIANT while things settle and I > catch up on driver state, and will likely send out an update next week > regarding which device drivers remain on the kill list, and generally what > the status of this project is. Here's the revised list of drivers that will have their build disabled in the next week (subject to an appropriate block of time for me): Name Bus Man page description ---- --- -------------------- ar ISA/PCI synchronous Digi/Arnet device driver arl ISA Aironet Arlan 655 wireless network adapter driver cnw ISA Netwave AirSurfer wireless network driver ic I2C I2C bus system oltr ISA/PCI Olicom Token Ring device driver plip PPBUS printer port Internet Protocol driver ppp TTY point to point protocol network interface ray PCCARD Raytheon Raylink/Webgear Aviator PCCard driver sbni ISA/PCI Granch SBNI12 leased line modem driver sbsh PCI Granch SBNI16 SHDSL modem device driver sl TTY slip network interface snc ISA/PCCARD National Semiconductor DP8393X SONIC Ethernet adapter driver sppp TTY point to point protocol network layer for synchronous lines sr ISA/PCI synchronous RISCom/N2 / WANic 400/405 device driver Obviously, if necessary work is done to remove the IFF_NEEDSGIANT requirement from a driver, it will be pulled from the list, and I'll do an IFF_NEEDSGIANT scan before pulling the plug. Drivers will remain in the tree but disconnected for about a month before being removed from HEAD. Thanks greatly to John and others who have worked hard to reduce the size of the list in the last year! The following USB drivers will remain enabled due to on-going USB work that should eliminate IFF_NEEDSGIANT: Name Bus Man page description ---- --- -------------------- axe USB ASIX Electronics AX88172 USB Ethernet driver cdce USB USB Communication Device Class Ethernet driver cue USB CATC USB-EL1210A USB Ethernet driver kue USB Kawasaki LSI KL5KUSB101B USB Ethernet driver rue USB RealTek RTL8150 USB to Fast Ethernet controller rum USB Ralink Technology USB IEEE 802.11a/b/g wireless network device udav USB Davicom DM9601 USB Ethernet driver ural USB Ralink Technology RT2500USB IEEE 802.11 driver zyd USB ZyDAS ZD1211/ZD1211B USB IEEE 802.11b/g wireless network device The following drivers reference IFF_NEEDSGIANT but only when running in an optional non-MPSAFE mode; that optional mode will be removed but the drivers will remain: Name Bus Man page description ---- --- -------------------- ce PCI driver for synchronous Cronyx Tau-PCI/32 WAN adapters cp PCI driver for synchronous Cronyx Tau-PCI WAN adapters ctau ISA driver for synchronous Cronyx Tau WAN adapters cx ISA driver for synchronous/asynchronous Cronyx Sigma WAN adapters Robert N M Watson Computer Laboratory University of Cambridge From joao.barros at gmail.com Mon Jun 30 10:10:31 2008 From: joao.barros at gmail.com (Joao Barros) Date: Mon Jun 30 10:10:35 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <20080630091033.P3968@fledge.watson.org> References: <20080524111715.T64552@fledge.watson.org> <20080629180126.F90836@fledge.watson.org> <20080630091033.P3968@fledge.watson.org> Message-ID: <70e8236f0806300243k69399808mf54ccb5796d395c0@mail.gmail.com> On Mon, Jun 30, 2008 at 9:27 AM, Robert Watson wrote: > The following USB drivers will remain enabled due to on-going USB work that > should eliminate IFF_NEEDSGIANT: Hi Robert, Is this on-going USB work just on the driver level or on the USB stack as well? I assume both need to be touched for MP safety. Who is doing this work? Joao Barros From bugmaster at FreeBSD.org Mon Jun 30 11:06:54 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 30 11:06:59 2008 Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org Message-ID: <200806301106.m5UB6rxC095686@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From Alexander at Leidinger.net Mon Jun 30 12:31:52 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Mon Jun 30 12:31:56 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <20080630091033.P3968@fledge.watson.org> References: <20080524111715.T64552@fledge.watson.org> <20080629180126.F90836@fledge.watson.org> <20080630091033.P3968@fledge.watson.org> Message-ID: <20080630141611.56172qs6gac45ri8@webmail.leidinger.net> Quoting Robert Watson (from Mon, 30 Jun 2008 09:27:11 +0100 (BST)): > > On Sun, 29 Jun 2008, Robert Watson wrote: > >> An FYI on the state of things here: in the last month, John has >> updated a number of device drivers to be MPSAFE, and the USB work >> remains in-flight. I'm holding fire a bit on disabling >> IFF_NEEDSGIANT while things settle and I catch up on driver state, >> and will likely send out an update next week regarding which device >> drivers remain on the kill list, and generally what the status of >> this project is. > > Here's the revised list of drivers that will have their build > disabled in the next week (subject to an appropriate block of time > for me): Is this list supposed to be complete (including dependencies)? bktr uses some I2C stuff and cxm (in ports) too. Bye, Alexander. -- meeting, n: An assembly of people coming together to decide what person or department not represented in the room must solve a problem. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From rwatson at FreeBSD.org Mon Jun 30 12:36:46 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Jun 30 12:36:57 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <20080630141611.56172qs6gac45ri8@webmail.leidinger.net> References: <20080524111715.T64552@fledge.watson.org> <20080629180126.F90836@fledge.watson.org> <20080630091033.P3968@fledge.watson.org> <20080630141611.56172qs6gac45ri8@webmail.leidinger.net> Message-ID: <20080630133335.K54631@fledge.watson.org> On Mon, 30 Jun 2008, Alexander Leidinger wrote: >> Here's the revised list of drivers that will have their build disabled in >> the next week (subject to an appropriate block of time for me): > > Is this list supposed to be complete (including dependencies)? bktr uses > some I2C stuff and cxm (in ports) too. As far as I'm aware, this list is complete. I compiled it by identifying all network device drivers that set (or may set) the IFF_NEEDSGIANT. With respect to i2c, this refers *only* to the if_ic.c network device driver, and not the other services associated with i2c, so bktr and other i2c consumers should be unaffected. I'm not familiar with cxm so can't comment on that. If you are aware of any other in-tree network device drivers that use IFF_NEEDSGIANT and aren't on the list, please do let me know. Robert N M Watson Computer Laboratory University of Cambridge From rwatson at FreeBSD.org Mon Jun 30 12:37:54 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Jun 30 12:38:03 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <70e8236f0806300243k69399808mf54ccb5796d395c0@mail.gmail.com> References: <20080524111715.T64552@fledge.watson.org> <20080629180126.F90836@fledge.watson.org> <20080630091033.P3968@fledge.watson.org> <70e8236f0806300243k69399808mf54ccb5796d395c0@mail.gmail.com> Message-ID: <20080630133649.P54631@fledge.watson.org> On Mon, 30 Jun 2008, Joao Barros wrote: > On Mon, Jun 30, 2008 at 9:27 AM, Robert Watson wrote: >> The following USB drivers will remain enabled due to on-going USB work that >> should eliminate IFF_NEEDSGIANT: > > Is this on-going USB work just on the driver level or on the USB stack as > well? I assume both need to be touched for MP safety. Who is doing this > work? I'm not familiar with the details of the on-going work, but as I understand it, all USB device drivers have been fully locked and the requirement for IFF_NEEDSGIANT is eliminated. Perhaps Hans, Warner, or Alfred could provide some further insight in this area. Robert N M Watson Computer Laboratory University of Cambridge From Alexander at Leidinger.net Mon Jun 30 13:17:25 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Mon Jun 30 13:17:29 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <20080630133335.K54631@fledge.watson.org> References: <20080524111715.T64552@fledge.watson.org> <20080629180126.F90836@fledge.watson.org> <20080630091033.P3968@fledge.watson.org> <20080630141611.56172qs6gac45ri8@webmail.leidinger.net> <20080630133335.K54631@fledge.watson.org> Message-ID: <20080630151714.13993elkvrzzzda8@webmail.leidinger.net> Quoting Robert Watson (from Mon, 30 Jun 2008 13:36:45 +0100 (BST)): > > On Mon, 30 Jun 2008, Alexander Leidinger wrote: > >>> Here's the revised list of drivers that will have their build >>> disabled in the next week (subject to an appropriate block of time >>> for me): >> >> Is this list supposed to be complete (including dependencies)? bktr >> uses some I2C stuff and cxm (in ports) too. > > As far as I'm aware, this list is complete. I compiled it by > identifying all network device drivers that set (or may set) the > IFF_NEEDSGIANT. With respect to i2c, this refers *only* to the > if_ic.c network device driver, and not the other services associated > with i2c, so bktr and other i2c consumers should be unaffected. I'm Ok. > not familiar with cxm so can't comment on that. If you are aware of > any other in-tree network device drivers that use IFF_NEEDSGIANT and > aren't on the list, please do let me know. I think cxm is similar to bktr in this regard (both are multimedia devices). Bye, Alexander. -- PARDON me, am I speaking ENGLISH? http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From hselasky at c2i.net Mon Jun 30 14:40:16 2008 From: hselasky at c2i.net (Hans Petter Selasky) Date: Mon Jun 30 14:40:21 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <70e8236f0806300243k69399808mf54ccb5796d395c0@mail.gmail.com> References: <20080524111715.T64552@fledge.watson.org> <20080630091033.P3968@fledge.watson.org> <70e8236f0806300243k69399808mf54ccb5796d395c0@mail.gmail.com> Message-ID: <200806301541.46177.hselasky@c2i.net> On Monday 30 June 2008, Joao Barros wrote: > On Mon, Jun 30, 2008 at 9:27 AM, Robert Watson wrote: > > The following USB drivers will remain enabled due to on-going USB work > > that should eliminate IFF_NEEDSGIANT: > > Hi Robert, > > Is this on-going USB work just on the driver level or on the USB stack > as well? I assume both need to be touched for MP safety. > Who is doing this work? > > Joao Barros > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" Hi, In the USB perforce project there are Giant free USB ethernet drivers, which have been around for quite a while. I am currently in the run-up renaming symbols so that my new USB stack can co-exist with the old USB stack. At least it will be possible to compile a kernel with both USB stacks. I suppose that USB ethernet drivers will no longer be available in the old USB stack ? References for FreeBSD developers: Before symbol rename: //depot/projects/usb/src/sys/dev/usb {if_xxx.c} After symbol rename: //depot/projects/usb/src/sys/dev/usb2/ethernet Others: http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/usb/src/sys/dev/usb2/ethernet&HIDEDEL=NO --HPS From hselasky at c2i.net Mon Jun 30 14:40:16 2008 From: hselasky at c2i.net (Hans Petter Selasky) Date: Mon Jun 30 14:40:29 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <70e8236f0806300243k69399808mf54ccb5796d395c0@mail.gmail.com> References: <20080524111715.T64552@fledge.watson.org> <20080630091033.P3968@fledge.watson.org> <70e8236f0806300243k69399808mf54ccb5796d395c0@mail.gmail.com> Message-ID: <200806301541.46177.hselasky@c2i.net> On Monday 30 June 2008, Joao Barros wrote: > On Mon, Jun 30, 2008 at 9:27 AM, Robert Watson wrote: > > The following USB drivers will remain enabled due to on-going USB work > > that should eliminate IFF_NEEDSGIANT: > > Hi Robert, > > Is this on-going USB work just on the driver level or on the USB stack > as well? I assume both need to be touched for MP safety. > Who is doing this work? > > Joao Barros > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" Hi, In the USB perforce project there are Giant free USB ethernet drivers, which have been around for quite a while. I am currently in the run-up renaming symbols so that my new USB stack can co-exist with the old USB stack. At least it will be possible to compile a kernel with both USB stacks. I suppose that USB ethernet drivers will no longer be available in the old USB stack ? References for FreeBSD developers: Before symbol rename: //depot/projects/usb/src/sys/dev/usb {if_xxx.c} After symbol rename: //depot/projects/usb/src/sys/dev/usb2/ethernet Others: http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/usb/src/sys/dev/usb2/ethernet&HIDEDEL=NO --HPS From jhb at freebsd.org Mon Jun 30 23:10:23 2008 From: jhb at freebsd.org (John Baldwin) Date: Mon Jun 30 23:10:28 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <20080629180126.F90836@fledge.watson.org> References: <20080524111715.T64552@fledge.watson.org> <20080629180126.F90836@fledge.watson.org> Message-ID: <200806301517.22173.jhb@freebsd.org> On Sunday 29 June 2008 01:02:49 pm Robert Watson wrote: > > On Sat, 24 May 2008, Robert Watson wrote: > > > Just as a reminder, we've just about reached the one month date before > > IFF_NEEDSGIANT drivers are disabled in the build. You can find a > > description of the general problem and list of specific drivers below. > > > > As USB work is on-going, I will *not* disable the USB drivers at this time, > > but all other drivers in the list below will be disabled on 26 June. They > > will remain in the tree, easily accessible for patch distribution and > > re-enabling, until October, when any remaining non-MPSAFE drivers will be > > deleted in 8.x. FreeBSD 8.0 will not ship with compatibility shims to > > support non-MPSAFE network device drivers. > > An FYI on the state of things here: in the last month, John has updated a > number of device drivers to be MPSAFE, and the USB work remains in-flight. > I'm holding fire a bit on disabling IFF_NEEDSGIANT while things settle and I > catch up on driver state, and will likely send out an update next week > regarding which device drivers remain on the kill list, and generally what the > status of this project is. Pending someone testing them real soon, I will be axeing at least sbsh, sbni, snc, and cnw this week (I had someone e-mail who said they would test the arl(4) pages). I still want to work on if_plip (which means locking ppbus) and if_ic (iicbus). I started working on locking iicbus recently FWIW. Aside from USB that leaves ray(4) (which does tsleep() all over the place including in interrupt handlers.. this couldn't have worked on 4.x all that well) and the various Cronyx drivers which interface with netgraph. Someone who knows netgraph can probably step up to lock those. Could also ask rik@ directly about the Cronyx drivers (cx, ctau, and cp). -- John Baldwin From jhb at freebsd.org Mon Jun 30 23:10:23 2008 From: jhb at freebsd.org (John Baldwin) Date: Mon Jun 30 23:10:29 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <20080629180126.F90836@fledge.watson.org> References: <20080524111715.T64552@fledge.watson.org> <20080629180126.F90836@fledge.watson.org> Message-ID: <200806301517.22173.jhb@freebsd.org> On Sunday 29 June 2008 01:02:49 pm Robert Watson wrote: > > On Sat, 24 May 2008, Robert Watson wrote: > > > Just as a reminder, we've just about reached the one month date before > > IFF_NEEDSGIANT drivers are disabled in the build. You can find a > > description of the general problem and list of specific drivers below. > > > > As USB work is on-going, I will *not* disable the USB drivers at this time, > > but all other drivers in the list below will be disabled on 26 June. They > > will remain in the tree, easily accessible for patch distribution and > > re-enabling, until October, when any remaining non-MPSAFE drivers will be > > deleted in 8.x. FreeBSD 8.0 will not ship with compatibility shims to > > support non-MPSAFE network device drivers. > > An FYI on the state of things here: in the last month, John has updated a > number of device drivers to be MPSAFE, and the USB work remains in-flight. > I'm holding fire a bit on disabling IFF_NEEDSGIANT while things settle and I > catch up on driver state, and will likely send out an update next week > regarding which device drivers remain on the kill list, and generally what the > status of this project is. Pending someone testing them real soon, I will be axeing at least sbsh, sbni, snc, and cnw this week (I had someone e-mail who said they would test the arl(4) pages). I still want to work on if_plip (which means locking ppbus) and if_ic (iicbus). I started working on locking iicbus recently FWIW. Aside from USB that leaves ray(4) (which does tsleep() all over the place including in interrupt handlers.. this couldn't have worked on 4.x all that well) and the various Cronyx drivers which interface with netgraph. Someone who knows netgraph can probably step up to lock those. Could also ask rik@ directly about the Cronyx drivers (cx, ctau, and cp). -- John Baldwin