Re: FreeBSD 5/6/7 kernel emulator for NetBSD 2.x
On Saturday 29 October 2005 06:59 am, Rui Paulo wrote: > On 2005.10.29 00:01:42 -0600, M. Warner Losh wrote: > | In message: <[EMAIL PROTECTED]> > | > | Rui Paulo <[EMAIL PROTECTED]> writes: > | : On 2005.10.26 10:22:52 -0700, Bill Studenmund wrote: > | : | On Mon, Oct 24, 2005 at 10:35:47PM +0200, Hans Petter Selasky wrote: > | : | > Main features: > | : | > > | : | > - Implements FreeBSD's devfs on NetBSD. > | : | > | : | In the past, we (NetBSD folks) have talked about a devfs. One issue > | : | that has come up (I'll be honest, I've raised it a lot) is a desire > | : | to retain permission changes across boots, and to tie devices (when > | : | possible) to a device-specific attribute rather than a probe order. > | : | > | : | Does FreeBSD's devfs support locators and persistent information? Are > | : | there plans to support something like that, if not? > | : > | : I remember Linux's devfs having a configure file for that particular > | : objective. The user would set the permission flags in (I can't recall > | : if this is the real name) /etc/devfsd.conf and let devfsd do the job. > | : > | : You could also use another directory for permissions, like /dev-state, > | : but personally, I don't like this method. > | : > | : http://www.atnf.csiro.au/people/rgooch/linux/docs/devfs.html#persistenc > | :e > | > | FreeBSD also has a file that can be used to control the permissions > | and ownerships at runtime. The persistance can be there, but isn't > | there by default like the old nodes in /dev. > > The other problem I see here is how devfs works in single user mode > where devfsd is not started and no permissions are set. How does > FreeBSD solve this problem? Well, for one thing you generally are root in single user mode such that permissions on /dev aren't quite as important as multi-user. :) However, the devfs rulesets are managed in the kernel, and there isn't a userland devfsd, so you could always manually set or load the devfs rules you want to apply while you are in single user. I think the biggest thing to think about is that devfs makes you think about /dev differently. It's more of a true psuedo-filesystem where there aren't actual files representing devices like the special device nodes that mapped to specfs. It's more like procfs. Do you ty to solve the problem of persistent permissions for files in /proc? -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5/6/7 kernel emulator for NetBSD 2.x
On 2005.10.29 00:01:42 -0600, M. Warner Losh wrote: | In message: <[EMAIL PROTECTED]> | Rui Paulo <[EMAIL PROTECTED]> writes: | : On 2005.10.26 10:22:52 -0700, Bill Studenmund wrote: | : | On Mon, Oct 24, 2005 at 10:35:47PM +0200, Hans Petter Selasky wrote: | : | > | : | > Main features: | : | > | : | > - Implements FreeBSD's devfs on NetBSD. | : | | : | In the past, we (NetBSD folks) have talked about a devfs. One issue that | : | has come up (I'll be honest, I've raised it a lot) is a desire to retain | : | permission changes across boots, and to tie devices (when possible) to a | : | device-specific attribute rather than a probe order. | : | | : | Does FreeBSD's devfs support locators and persistent information? Are | : | there plans to support something like that, if not? | : | : I remember Linux's devfs having a configure file for that particular | : objective. The user would set the permission flags in (I can't recall | : if this is the real name) /etc/devfsd.conf and let devfsd do the job. | : | : You could also use another directory for permissions, like /dev-state, | : but personally, I don't like this method. | : | : http://www.atnf.csiro.au/people/rgooch/linux/docs/devfs.html#persistence | | FreeBSD also has a file that can be used to control the permissions | and ownerships at runtime. The persistance can be there, but isn't | there by default like the old nodes in /dev. The other problem I see here is how devfs works in single user mode where devfsd is not started and no permissions are set. How does FreeBSD solve this problem? -- Rui Paulo pgpCCvNW3htMU.pgp Description: PGP signature
Re: FreeBSD 5/6/7 kernel emulator for NetBSD 2.x
In message: <[EMAIL PROTECTED]> Rui Paulo <[EMAIL PROTECTED]> writes: : On 2005.10.26 10:22:52 -0700, Bill Studenmund wrote: : | On Mon, Oct 24, 2005 at 10:35:47PM +0200, Hans Petter Selasky wrote: : | > : | > Main features: : | > : | > - Implements FreeBSD's devfs on NetBSD. : | : | In the past, we (NetBSD folks) have talked about a devfs. One issue that : | has come up (I'll be honest, I've raised it a lot) is a desire to retain : | permission changes across boots, and to tie devices (when possible) to a : | device-specific attribute rather than a probe order. : | : | Does FreeBSD's devfs support locators and persistent information? Are : | there plans to support something like that, if not? : : I remember Linux's devfs having a configure file for that particular : objective. The user would set the permission flags in (I can't recall : if this is the real name) /etc/devfsd.conf and let devfsd do the job. : : You could also use another directory for permissions, like /dev-state, : but personally, I don't like this method. : : http://www.atnf.csiro.au/people/rgooch/linux/docs/devfs.html#persistence FreeBSD also has a file that can be used to control the permissions and ownerships at runtime. The persistance can be there, but isn't there by default like the old nodes in /dev. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5/6/7 kernel emulator for NetBSD 2.x
On Thu, Oct 27, 2005 at 04:53:35PM -0400, der Mouse wrote: > >>> - Implements FreeBSD's devfs on NetBSD. > >> In the past, we (NetBSD folks) have talked about a devfs. > >> [...persistence...] > > FreeBSD 5+ has /etc/devfs.conf and /etc/devfs.rules [...]. Is that > > what you're looking for? > > I didn't write what you're responding to, but, speaking personally: > > If making changes to /dev with chmod/chown/mv/etc results in those > files getting rewritten to match, it's fine. If not, it's not. I think that having those changes propogated to the userland config files would be very good. I'd really want NetBSD to do it, and I bet it could be a useful feature for FreeBSD too. Take care, Bill pgpPFSuyGvQ6e.pgp Description: PGP signature
Re: FreeBSD 5/6/7 kernel emulator for NetBSD 2.x
On Thursday 27 October 2005 18:10, Bill Studenmund wrote: > On Thu, Oct 27, 2005 at 09:29:52AM +0200, [EMAIL PROTECTED] wrote: > > On Wed, Oct 26, 2005 at 05:48:06PM -0700, Bill Studenmund wrote: > > > The reason I'm interested in locators is so that if devices renumber > > > themselves, the permissions follow. I am assuming, but I think we'd > > > rather not use locators for names (/dev/sd.52004567BA64678D anyone?). > > > But if we can tie the permissions to a locator, then it doesn't matter > > > if it's sd2 or sd12. :-) > > > > I think it does matter, because all userland programs use device names, > > not locators. If permissions are enforced by an userland program, they > > will not follow locators. > > Oh, but part of all of this would be that userland would be able to find > out the locators for a device! It won't work any other way. > I was thinking that one could mount devfs on /dev/dev, and then make some symlinks from /dev/ to /dev/dev/, hence it is not possible to union mount anything on /dev. Then symlinks and permissions can be managed by a daemon reading the configuration from "/etc/devfs.conf", like on "FreeBSD". Another problem about /dev as a file system, is that one will possibly not find all the devices on the system, without being a kernel expert. And the major/minor numering is not easy, like mentioned by someone else. On Wednesday 26 October 2005 02:09, Lennart Augustsson wrote: > You'll never get a driver that looks exactly right for one > OS to work with another, even with an emulation layer. That is what I have done. Remember, my emulator is not sandwitched between the driver and the NetBSD kernel. It is more like something that sits beside the NetBSD kernel. Else this task would be nearly impossible, due to the differences between NetBSD and FreeBSD. So if you put a driver under my emulation layer, it will not be a child of the NetBSD device system, but the FreeBSD device system. > For instance, FreeBSD doesn't have an activate method for > device drivers whereas NetBSD and OpenBSD do. There is no problem adding a "device_activate" method to the FreeBSD drivers, though it will only be used on NetBSD/OpenBSD and alike· In fact, you can add any method you like to any device. > And there are examples of the reverse. So shared drivers > will have some clutter. I see that there are some problems, but no big problems. For example on FreeBSD there is no parent bus_dma_tag for PCI devices. But there is no problem to add something like "device_get_parent_dma_tag(device_t *dev)" that will return "NULL" on FreeBSD and the correct value on NetBSD. Merging these smaller differences will be the least problem. The situation is like this, that having two branches of a driver is double work for the maintainer. And maybe this is the reason some drivers are only available on one system. And when one can spend twice as much time on something, it should be better. Shouldn't it be easier to port kernel software between FreeBSD and NetBSD? When it comes to mutexes I want to say that FreeBSD's "struct mtx" is portable to NetBSD without any problems. But when a NetBSD driver is ported to FreeBSD, it will fall under the Giant lock, possibly forcing other parts of the kernel under Giant aswell. Giant is bad, because it puts a single lock on the kernel. Moving some piece of code out of Giant is sometimes easy, but from my experience, it can require a lot of work. Locking is not just that simple. An advantage about non-tsleep-able mutexes, is that one can warn the user when a function that can sleep is called, depending on the context. This might be as innocent as allocating some memory while holding a mutex, which many think will not cause a sleep. So code using its own mutexes, is really preferred, or is it not so important with mutexes? --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5/6/7 kernel emulator for NetBSD 2.x
Bill Studenmund wrote this message on Wed, Oct 26, 2005 at 10:22 -0700: > On Mon, Oct 24, 2005 at 10:35:47PM +0200, Hans Petter Selasky wrote: > > > > Main features: > > > > - Implements FreeBSD's devfs on NetBSD. > > In the past, we (NetBSD folks) have talked about a devfs. One issue that > has come up (I'll be honest, I've raised it a lot) is a desire to retain > permission changes across boots, and to tie devices (when possible) to a > device-specific attribute rather than a probe order. > > Does FreeBSD's devfs support locators and persistent information? Are > there plans to support something like that, if not? Well, there are two camps (there may be more, but I can only think of these two) to the locators and persistent info... One is the geom_label route, where the devices self identify, so no matter what adX a device appears as, you can just mount /dev/ufs/fsname... The other of course is to allow you to wire down devices... which some things are better about allowing than others.. like you can wire down da and sio devices... Though one things I miss on FreeBSD that MacOSX has is that when you plug in a USB to serial adapter, MacOSX includes the serial number in the device name: /dev/tty.usbserial-FTC8P121, which is convient... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5/6/7 kernel emulator for NetBSD 2.x
On October 26, 2005 10:22 am, Bill Studenmund wrote: > On Mon, Oct 24, 2005 at 10:35:47PM +0200, Hans Petter Selasky wrote: > > Main features: > > - Implements FreeBSD's devfs on NetBSD. > In the past, we (NetBSD folks) have talked about a devfs. One issue > that has come up (I'll be honest, I've raised it a lot) is a desire to > retain permission changes across boots, and to tie devices (when > possible) to a device-specific attribute rather than a probe order. FreeBSD 5+ has /etc/devfs.conf and /etc/devfs.rules which include information regarding permissions and ownership for device nodes under /dev. These files can even be used for creating fancy names for devices using symlinks (like /dev/burner for CD-RW devices, or /dev/floppy and so on). At boot time, /etc/devfs.conf is read, and /etc/devfs.rules is read whenever new devices are attached to the system (I believe that's how it works, anyway). Is that what you're looking for? > Does FreeBSD's devfs support locators and persistent information? Are > there plans to support something like that, if not? -- Freddie Cash [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5/6/7 kernel emulator for NetBSD 2.x
On Mon, Oct 24, 2005 at 10:35:47PM +0200, Hans Petter Selasky wrote: > > Main features: > > - Implements FreeBSD's devfs on NetBSD. In the past, we (NetBSD folks) have talked about a devfs. One issue that has come up (I'll be honest, I've raised it a lot) is a desire to retain permission changes across boots, and to tie devices (when possible) to a device-specific attribute rather than a probe order. Does FreeBSD's devfs support locators and persistent information? Are there plans to support something like that, if not? Take care, Bill pgpr3OJEGJ3wV.pgp Description: PGP signature
Re: FreeBSD 5/6/7 kernel emulator for NetBSD 2.x
On Oct 26, 2005, at 10:22 AM, Bill Studenmund wrote: In the past, we (NetBSD folks) have talked about a devfs. One issue that has come up (I'll be honest, I've raised it a lot) is a desire to retain permission changes across boots, and to tie devices (when possible) to a device-specific attribute rather than a probe order. The permission thing is solvable using scripts that can fix up the perms after mount. The "nodes named after attributes" thing is interesting... and largely something I'm concerned about with wedges, although in that case, it's pretty easy to handle from within wedges itself. Does FreeBSD's devfs support locators and persistent information? Are there plans to support something like that, if not? FreeBSD's devfs does not, to my knowledge, include the things that you have mentioned above. FWIW, I think a devfs based on our new tmpfs would be better for NetBSD. -- thorpej ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5/6/7 kernel emulator for NetBSD 2.x
In message <[EMAIL PROTECTED]>, Jason Thorpe writes: > >FWIW, I think a devfs based on our new tmpfs would be better for NetBSD. > I was under the impression that each i-node in tmpfs consumed a fair amount of space, making it a bad match for things like /dev which have very many i-nodes but no actual files. (Well, I've seen glitches on ancient systems where /dev/null got turned into a regular file, leading to amusing messages about "/dev/null: no space left on device"...) --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5/6/7 kernel emulator for NetBSD 2.x
You'll never get a driver that looks exactly right for one OS to work with another, even with an emulation layer. For instance, FreeBSD doesn't have an activate method for device drivers whereas NetBSD and OpenBSD do. And there are examples of the reverse. So shared drivers will have some clutter. Personally, I prefer the macros. -- Lennart Hans Petter Selasky wrote: Hi, I have made an effort on making a FreeBSD 5/6/7 kernel emulator for NetBSD 2.x. Many device drivers are shared between these two operating systems, and I think a lot of work can be saved when it comes to porting code and patches forth and back. Currently this emulator makes my FreeBSD PCI ISDN driver load and run on NetBSD. I have chosen to make FreeBSD 5+ the standard for several reasons: - all drivers are dynamically linked through use of the "section attribute" in the "C" compiler. - "/dev" is a file system that can be manipulated from the kernel, without intervention from "mknod". - All I/O resources are allocated through a single function, "bus_alloc_resource()". - And more. Here is a case in which such a kernel emulator can be used: I think it is a good idea that FreeBSD and NetBSD shares as many USB drivers as possible. But sharing USB device drivers like "/usr/src/sys/dev/usb/ulpt.c", is difficult, because two quite different interfaces are used to create devices in "/dev/". And it is not only this, but also how USB device drivers register in the kernel so that they get probed. Here one has tried to hide system differences by using macros. I think one should rather have some external library that hides these system differences, so that there is only one branch for the USB device drivers, for both NetBSD and FreeBSD, and probably the other *BSD's aswell, if possible. That means a branch without "ifdefs" for every operating system it is supposed to compile on. Then one has got to choose the library interface, and I would say that "FreeBSD 5+ specific" is the best candidate so far. I see that one can move many USB drivers over to FreeBSD, merge everything together, expand all the macros in "/usr/src/sys/dev/usb/usb_port.h", and then copy it back to NetBSD which then must have a FreeBSD kernel emulator in the kernel. When the drivers are updated later, it will be very easy to cross port the changes, and at the same time the USB system is brought out of the Giant lock. Also it will be easier to create portable USB kernel device drivers. Anyone have any opinion about what system is better to use as a standard in the kernel? Main features: - Implements FreeBSD's devfs on NetBSD. - Support for mutexes, mtx_() and msleep() - Support for probe/attach and general use of PCI devices - Support for SYSINIT() - Support for DRIVER_MODULE() - And some other things found in FreeBSD 5/6/7 Here is a tarball (only tested on i386 and compatible, NetBSD 2.x): http://home.c2i.net/hselasky/isdn4bsd/privat/temporary/new_ihfc_1_5_5_NetBSD.tar.bz2 --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD 5/6/7 kernel emulator for NetBSD 2.x
Hi, I have made an effort on making a FreeBSD 5/6/7 kernel emulator for NetBSD 2.x. Many device drivers are shared between these two operating systems, and I think a lot of work can be saved when it comes to porting code and patches forth and back. Currently this emulator makes my FreeBSD PCI ISDN driver load and run on NetBSD. I have chosen to make FreeBSD 5+ the standard for several reasons: - all drivers are dynamically linked through use of the "section attribute" in the "C" compiler. - "/dev" is a file system that can be manipulated from the kernel, without intervention from "mknod". - All I/O resources are allocated through a single function, "bus_alloc_resource()". - And more. Here is a case in which such a kernel emulator can be used: I think it is a good idea that FreeBSD and NetBSD shares as many USB drivers as possible. But sharing USB device drivers like "/usr/src/sys/dev/usb/ulpt.c", is difficult, because two quite different interfaces are used to create devices in "/dev/". And it is not only this, but also how USB device drivers register in the kernel so that they get probed. Here one has tried to hide system differences by using macros. I think one should rather have some external library that hides these system differences, so that there is only one branch for the USB device drivers, for both NetBSD and FreeBSD, and probably the other *BSD's aswell, if possible. That means a branch without "ifdefs" for every operating system it is supposed to compile on. Then one has got to choose the library interface, and I would say that "FreeBSD 5+ specific" is the best candidate so far. I see that one can move many USB drivers over to FreeBSD, merge everything together, expand all the macros in "/usr/src/sys/dev/usb/usb_port.h", and then copy it back to NetBSD which then must have a FreeBSD kernel emulator in the kernel. When the drivers are updated later, it will be very easy to cross port the changes, and at the same time the USB system is brought out of the Giant lock. Also it will be easier to create portable USB kernel device drivers. Anyone have any opinion about what system is better to use as a standard in the kernel? Main features: - Implements FreeBSD's devfs on NetBSD. - Support for mutexes, mtx_() and msleep() - Support for probe/attach and general use of PCI devices - Support for SYSINIT() - Support for DRIVER_MODULE() - And some other things found in FreeBSD 5/6/7 Here is a tarball (only tested on i386 and compatible, NetBSD 2.x): http://home.c2i.net/hselasky/isdn4bsd/privat/temporary/new_ihfc_1_5_5_NetBSD.tar.bz2 --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
