Re: what is devfs?
Warner Losh wrote: In message [EMAIL PROTECTED] Wes Peters writes: : Is there any possibility of creating a database of devfs perms that gets : loaded into kernel-accessible data space by the loader before boot? Once : the system is up, devfsd could take over, monitoring and updating the : state of devfs and this database, and the perms would come up as they were : last set, modulo the cycle time of devfsd. Hmmm. That's an interesting possibility. If we could load this database from the boot loader, then we could have a good snapshot of the user's desired persistance. This would allow the kernel to have a template for the permissions as the devices are coming up... Interesting possibilities here. This sounds a lot like the notion that I've had for a while of having a Xdefaults-like database to pass parameters to device instances. This would be just another parameter... Might not even need a devfsd in a case like this, if you don't mind your /dev tree being configured in a manner that is different than in prior versions. Or in other words, why stop with just the owner, group, flags and permission bits. Why not save other things as well... Interrupt, DMA, I/O settings, promiscuous operation, baud rate and parity, etc. Any little thing a device driver might desire... -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
In message [EMAIL PROTECTED] Wes Peters writes: : Interrupt, DMA, I/O settings, promiscuous operation, baud rate and parity, : etc. Any little thing a device driver might desire... I had been specifically thinking of things more obscure like the WNETID for wavelan cards, the frequency ranges for the bktr cards, the frequency pattern for an ibm lan entry driver I never finished, the preferred media type for ethernet drivers, the calibrated frequency for clock boards/parts, the mixer settings from sound drivers, etc, etc, etc. These things are closely related to the more prosaic things like I/O range, IRQ, DRQ, etc. I'm not sure that the differences between "configuration" data and other attributes not necessarily common to a bus are significant enough to warrant special treatment. I gotta find some time to get into this more deeply. Maybe after pccard has grown cardbus support :-). And the sysctl mechanism might not be a bad one to make persistant. However, there are some issues with having multiple instances of sysctls that would need to be generically solved at the same time. There, the whole problem of the persistant parts of devfsd has been reduced to basically /etc/rc.sysctl which should make the "we don't need devfsd to do persitance" folks happy. :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
Warner Losh wrote: In message [EMAIL PROTECTED] Wes Peters writes: : Interrupt, DMA, I/O settings, promiscuous operation, baud rate and parity, : etc. Any little thing a device driver might desire... I had been specifically thinking of things more obscure like the WNETID for wavelan cards, the frequency ranges for the bktr cards, the frequency pattern for an ibm lan entry driver I never finished, the preferred media type for ethernet drivers, the calibrated frequency for clock boards/parts, the mixer settings from sound drivers, etc, etc, etc. These things are closely related to the more prosaic things like I/O range, IRQ, DRQ, etc. I'm not sure that the differences between "configuration" data and other attributes not necessarily common to a bus are significant enough to warrant special treatment. I gotta find some time to get into this more deeply. Maybe after pccard has grown cardbus support :-). And the sysctl mechanism might not be a bad one to make persistant. However, there are some issues with having multiple instances of sysctls that would need to be generically solved at the same time. I'm sure you can handle the easy stuff, now that I've done the genius part. ;^) There, the whole problem of the persistant parts of devfsd has been reduced to basically /etc/rc.sysctl which should make the "we don't need devfsd to do persitance" folks happy. :-) Yup. All we have to do is make the API modify the driver AND the database, and load the database so the drivers can get at the info a boot time. This design work is kinda fun, I wonder if I can get somebody to pay me to do it? Nah, they always end up wanting me to write code (i.e. WORK) for a living. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
On Mon, 20 Sep 1999, Julian Elischer wrote: as I explained a few days ago, MFS explodes because it synthesises a device vnode The synthesized vnode is someohow confused as to whether it's a devfs vnode or a UFS vnode. I can't remember the exact problem but it may have something to do with using it as a methid aof getting to teh strategy routine.. I don't remember exaclty, but I think it may be possible to not do that any more. I discovered this the hard way when I tried to build picobsd floppy with DEVFS. If you look in the archives, I think I posted the complete backtrace. Andrzej Bialecki // [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
Julian Elischer scribbled this message on Sep 20: POLA! if we have persisten permissions and ownership, and we allow renaming, then renaming should also be persistant... after the mount again, da0c either no longer exists, or is no longer ttyd1... which neither is an acceptable solution... I think at this stage you've gone overboard.. part of the definition of devfs is that a device shows up on mount with it's canonical name.. On each new mount every time, even if you've mounted it in 10 different places. I didn't flat out state it, but I think persistant should NOT be done via an underlying node, but via a daemon... and then this would be a moot point as you'd just configure the daemon to do what you need to do, or run an /etc/rc.devfs script which sets the permission properly.. a) all existing device nodes show up b) all nodes are gives root:wheel 0600 permissions at start that is all I'm looking for... anything else is stupid or complex... hell, a daemon could be something as simple as a script that constantly sees if a device has root:wheel 0600 permissions, and set them correctly if they don't... persitance is stupid UNLESS it is complete persitance... and you've said that complete persitance is to complex, so lets go w/ no persitance, and default secure premissions... -- John-Mark Gurney Voice: +1 408 975 9651 Cu Networking "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
Matthew Dillon wrote:
I think devfs is really cool. I don't think it needs to have
fancy persistence in order to be useful.
Likewise. I find myself never needing to change device permissions.
I do wish however that there were some sort of "template" options for
classes of names.
The way I imagine it would work would be like this:
By default, all devices start out as root:wheel, 0600.
We can then change the default permissions by "class". For example, devices
may be grouped something like this: disk, tape, tty, cua, pty, vty, etc.
Then, we could change the default permissions by class, with something like
this in a rc.* script:
sysctl -w devfs.template.mode.cua=0660
sysctl -w devfs.template.owner.cua=`id -u uucp`
sysctl -w devfs.template.group.cua=`id -g dialer`
sysctl -w devfs.template.mode.disk=0620
sysctl -w devfs.template.group.disk=`id -g operator`
sysctl -w devfs.template.mode.pty=0666
sysctl -w devfs.template.group.pty=`id -g tty`
... and so on.
For this to work well, devices should track their "template" until they are
explicitly given their own modes. For example, doing a chmod on /dev/rst0
will seperate it from the "tape" class. Until that point, it's modes change
every time the template is changed. This allows us to boot with reasonable
defaults and explicitly give permissions in bulk and still DTRT with devices
appearing (eg: usb devices).
An alternative to abusing sysctl might be to have some pseudo devices in
(say) /dev/template/{pty,disk,tape,} that can be directly tweaked with
chmod/chown/etc..
Cheers,
-Peter
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
On Tue, 21 Sep 1999, John-Mark Gurney wrote: Julian Elischer scribbled this message on Sep 20: POLA! if we have persisten permissions and ownership, and we allow renaming, then renaming should also be persistant... after the mount again, da0c either no longer exists, or is no longer ttyd1... which neither is an acceptable solution... I think at this stage you've gone overboard.. part of the definition of devfs is that a device shows up on mount with it's canonical name.. On each new mount every time, even if you've mounted it in 10 different places. I didn't flat out state it, but I think persistant should NOT be done via an underlying node, but via a daemon... and then this would be a moot point as you'd just configure the daemon to do what you need to do, or run an /etc/rc.devfs script which sets the permission properly.. I distrust the complexity of daemons in this case, for something as important as device permissions. that is all I'm looking for... anything else is stupid or complex... Stupid, is that a technical term? hell, a daemon could be something as simple as a script that constantly sees if a device has root:wheel 0600 permissions, and set them correctly if they don't... Security controlled by a script, Yikes! persitance is stupid UNLESS it is complete persitance... and you've said Why? Is this a technical judgment, or personal prejudice? that complete persitance is to complex, so lets go w/ no persitance, and default secure premissions... Because initial security (boot time) is important, and complex solutions are prone to holes. Another daemon, is yet one more process, sucking up resources, prone to attack. If I can hack your devfsd, I can give myself permissions to do anything to your system. Brian Beattie| The only problem with [EMAIL PROTECTED] | winning the rat race ... www.aracnet.com/~beattie | in the end you're still a rat To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
On Mon, 20 Sep 1999, Julian Elischer wrote: POLA! if we have persisten permissions and ownership, and we allow renaming, then renaming should also be persistant... after the mount again, da0c either no longer exists, or is no longer ttyd1... which neither is an acceptable solution... I think at this stage you've gone overboard.. Gee, I'd have to agree on this one. part of the definition of devfs is that a device shows up on mount with it's canonical name.. On each new mount every time, even if you've mounted it in 10 different places. Absolutely correct, canonical names only, why don't you try to rename files in /proc? You've taken this one too far this time. Chuck Robey| Interests include C programming, Electronics, 213 Lakeside Dr. Apt. T-1 | communications, and signal processing. Greenbelt, MD 20770| I run picnic.mat.net: FreeBSD-current(i386) and (301) 220-2114 | jaunt.mat.net : FreeBSD-current(Alpha) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
On Tue, 21 Sep 1999, Peter Wemm wrote: Matthew Dillon wrote: I think devfs is really cool. I don't think it needs to have fancy persistence in order to be useful. Likewise. I find myself never needing to change device permissions. I often change perms on the bpf device so that members of the wheel group can read it. -- Ben Rosengart UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
In message [EMAIL PROTECTED] Tony Finch writes: : Why not just do a one-off checkpoint at shutdown time? Why do you need : to track the changes as they happen? Power failures. Also, if the device is new, it might be nice to have commands that run when they arrive in the tree (think pccard). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
Can everybody please remember that the argument about whether persistence is good, or the devil's invention, has already been totally beaten to death, and it's in the mail archives. Most of you have been working towards defining an acceptable compromise, but if your post gives your opinion about persistence, please save it, you're doing us no service! We don't need more heat on the question, we need a path to solution. Chuck Robey| Interests include C programming, Electronics, 213 Lakeside Dr. Apt. T-1 | communications, and signal processing. Greenbelt, MD 20770| I run picnic.mat.net: FreeBSD-current(i386) and (301) 220-2114 | jaunt.mat.net : FreeBSD-current(Alpha) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
On Tue, 21 Sep 1999, Ben Rosengart wrote: On Tue, 21 Sep 1999, Peter Wemm wrote: Matthew Dillon wrote: I think devfs is really cool. I don't think it needs to have fancy persistence in order to be useful. Likewise. I find myself never needing to change device permissions. I often change perms on the bpf device so that members of the wheel group can read it. do you do this in /etc/rc.local? any reason you couldn't still do this? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
Devices must failsafe from a security point of view in the absense of a devfsd. Otherwise there will extreme opposition from the security officer. This means 0600 or more restrictive permissions. While it doesn't happen often, it must be designed for. Otherwise you've replaced a secure, predictible system with an insecure one, which is not acceptible at all in the base FreeBSD product. How permissions are saved, devices are given out for use I don't care too much about so long as it is secure. In general, it is very hard to secure a system where things aren't predictable. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
Warner Losh wrote: Devices must failsafe from a security point of view in the absense of a devfsd. Otherwise there will extreme opposition from the security officer. This means 0600 or more restrictive permissions. While it doesn't happen often, it must be designed for. Otherwise you've replaced a secure, predictible system with an insecure one, which is not acceptible at all in the base FreeBSD product. How permissions are saved, devices are given out for use I don't care too much about so long as it is secure. In general, it is very hard to secure a system where things aren't predictable. Is there any possibility of creating a database of devfs perms that gets loaded into kernel-accessible data space by the loader before boot? Once the system is up, devfsd could take over, monitoring and updating the state of devfs and this database, and the perms would come up as they were last set, modulo the cycle time of devfsd. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
In message [EMAIL PROTECTED] Wes Peters writes: : Is there any possibility of creating a database of devfs perms that gets : loaded into kernel-accessible data space by the loader before boot? Once : the system is up, devfsd could take over, monitoring and updating the : state of devfs and this database, and the perms would come up as they were : last set, modulo the cycle time of devfsd. Hmmm. That's an interesting possibility. If we could load this database from the boot loader, then we could have a good snapshot of the user's desired persistance. This would allow the kernel to have a template for the permissions as the devices are coming up... Interesting possibilities here. This sounds a lot like the notion that I've had for a while of having a Xdefaults-like database to pass parameters to device instances. This would be just another parameter... Might not even need a devfsd in a case like this, if you don't mind your /dev tree being configured in a manner that is different than in prior versions. Or in other words, why stop with just the owner, group, flags and permission bits. Why not save other things as well... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
In message [EMAIL PROTECTED] Matthew Dillon writes: :Personally speaking I don't see how permission persistence could possibly :be implemented within DEVFS itself without a huge amount of work. I'm :not sure it would be appropriate to implement it there anyhow when it :is so easy to just make the necessary changes in rc.local. I wrote about 50% of a devd that would sit and watch a /devfs mounted tree, recording changes to it and would then replay those changes when it was started again. I ran into some interesting problems making it fast, but this work predates jdp's work on having a tree watching interface. rc.local is a religious war and a security nightmare waiting to happen :-). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
In message [EMAIL PROTECTED] "Matthew N. Dodd" writes: : Seems like a devfsd using the file monitoring hooks would work; you'd only : update the persistent store if you were running devfsd. devfsd would read : the store and init /dev with the contents. I think the only issue that : would involve thinking would be whiteouts (and the actual devfsd code of : course.) Yes. That's my thinking as well. I was also thinking of having devfsd do more than simpler persistance. I had plans, which I never tried to implement, of having it assume some of the roles of pccardd and usbd... Too bad I've lost the original start I made on devfsd. At least I can't find it on my home systems right now. I fear I either lost it in a disk crash, or when I left my last employer... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
On Sun, 19 Sep 1999, Chuck Robey wrote: On Sun, 19 Sep 1999, Julian Elischer wrote: On Sun, 19 Sep 1999, Chuck Robey wrote: On Sat, 18 Sep 1999, Julian Elischer wrote: DEVFS itself works fine however a subsystem it required to be a useful abstraction was vandalised and stripped out by some people who "didn't get it" and it has not yet been replaced by equivalent code. It seems more correct (to me) to state that there was a furious disagreement over whether or not to allow some memory of file permissions in devfs. Since there was never any agreement, DEVFS has smoldered. I think there's general agreement it would be a good thing to have, but that argument over how to keep user configurations must be handled. file permissions were not relevant to the code that was ripped out (the stackable disk partitionning layers) (called SLICE). But it was to the subject on the Subject: line, Julian. We know what side you're on, but there are 2 sides to the argument. Isn't there some way that it can be set up to *optionally* have permission persistence? I was one of the early consumers of DEVFS/SLICE. It mostly worked then, without any persistance. What Julian is saying is that there was some point in time when the things worked as they should for the DEVFS, just without keeping any persistance. The code which was removed had nothing to do with the persistance either. So, as it is now DEVFS doesn't work properly, but not because of the lack of persistance or some disagreements on this issue - it's just missing the SLICE code. Andrzej Bialecki // [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
On Sun, 19 Sep 1999, Matthew Dillon wrote: :Whatever, let's please not get into an argument over persistence, it's in :the archives. : : :Chuck Robey| Interests include C programming, Electronics, Personally speaking I don't see how permission persistence could possibly be implemented within DEVFS itself without a huge amount of work. I'm not sure it would be appropriate to implement it there anyhow when it is so easy to just make the necessary changes in rc.local. I know your opinions (and I know they're shared by others) but that's precisely what I asked to avoid above. Let's agree, at least, that there are two opinions on this; would it be possible, perhaps with a devfsd daemon, to allow a user to choose whether or not to have persistent permissions outside of rc.local? I'm not asking you to write this (I wouldn't ask you to code something you are personally opposed to); I'm asking if such an approach might make a compromise possible, so that devfs could maybe operate both ways (with without persistence)? Let's not get into an argument over whether persistence is good or not; let's see if we can make the argument pointless. Chuck Robey| Interests include C programming, Electronics, 213 Lakeside Dr. Apt. T-1 | communications, and signal processing. Greenbelt, MD 20770| I run picnic.mat.net: FreeBSD-current(i386) and (301) 220-2114 | jaunt.mat.net : FreeBSD-current(Alpha) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
In message [EMAIL PROTECTED] "Matthew N. Dodd" writes: : Well, with devd or devfsd its still going to read the persistant store : when started by the system on reboot; I'd imagine you'd be able to : make checkpoint intervals tunable and tell it which permission updates you : wanted to ignore and use the defaults; tty devices come to mind. Yes. That's true. That's why the idea of devfsd is simple, but implementing it well enough for people to be happy with it is much much harder. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
On Mon, 20 Sep 1999, Warner Losh wrote: Yes. That's true. That's why the idea of devfsd is simple, but implementing it well enough for people to be happy with it is much much harder. I think a minimal feature set for the first rev would satisify 90% of those wanting persistence no? ie just tracking permissions and owners for everything, and restoring them to their previous state on startup. This would require that devfsd be started fairly early. Adding a tunable checkpoint interval would be fairly simple. Beyond that it would be a matter of what specific features the 'power users' wanted. This simple behavior would nearly exactly mimic the behavior of a normal filesystem based /dev. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
Matthew N. Dodd scribbled this message on Sep 20: On Sun, 19 Sep 1999, Chuck Robey wrote: But it was to the subject on the Subject: line, Julian. We know what side you're on, but there are 2 sides to the argument. Isn't there some way that it can be set up to *optionally* have permission persistence? Seems like a devfsd using the file monitoring hooks would work; you'd only update the persistent store if you were running devfsd. devfsd would read the store and init /dev with the contents. I think the only issue that would involve thinking would be whiteouts (and the actual devfsd code of course.) one thing that HAS to happen is the fast that some devices CAN'T "appeare" until the devfsd says it can, unless we force a very restrictive permision on all devices (600 or something similar) otherwise we will have security wholes up the wazoo... don't forget about this... a devfsd daemon is definately the way to go... -- John-Mark Gurney Voice: +1 408 975 9651 Cu Networking "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
On Mon, 20 Sep 1999, John-Mark Gurney wrote: Matthew N. Dodd scribbled this message on Sep 20: On Sun, 19 Sep 1999, Chuck Robey wrote: But it was to the subject on the Subject: line, Julian. We know what side you're on, but there are 2 sides to the argument. Isn't there some way that it can be set up to *optionally* have permission persistence? Seems like a devfsd using the file monitoring hooks would work; you'd only update the persistent store if you were running devfsd. devfsd would read the store and init /dev with the contents. I think the only issue that would involve thinking would be whiteouts (and the actual devfsd code of course.) one thing that HAS to happen is the fast that some devices CAN'T "appeare" until the devfsd says it can, unless we force a very restrictive permision on all devices (600 or something similar) otherwise we will have security wholes up the wazoo... don't forget about this... a devfsd daemon is definately the way to go... While I sharply disagree, with your assertion, I also point out that if you make such a all-singing-all-dancing devfsd, then you might as well get rid of devfs entirely, and just have devfsd make the devices using normal mknod commands. -- John-Mark GurneyVoice: +1 408 975 9651 Cu Networking "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
Julian Elischer wrote: On Mon, 20 Sep 1999, John-Mark Gurney wrote: one thing that HAS to happen is the fast that some devices CAN'T "appeare" until the devfsd says it can, unless we force a very restrictive permision on all devices (600 or something similar) otherwise we will have security wholes up the wazoo... don't forget about this... a devfsd daemon is definately the way to go... While I sharply disagree, with your assertion, I also point out that if you make such a all-singing-all-dancing devfsd, then you might as well get rid of devfs entirely, and just have devfsd make the devices using normal mknod commands. Hmm - rip out the whole devfs infrastructure and replace it with something which writes tuples of (operation, devname, major, minor) to a socket somewhere, where "operation" is "create", "delete", "online", "offline", etc. Why worry about the complexities of a vfs to handle /dev in the kernel when almost all of it can be done in userland? [ Heh. *now* there'll be some wailing and gnashing of teeth... :-) ] - mark Mark Newton Email: [EMAIL PROTECTED] (W) Network Engineer Email: [EMAIL PROTECTED] (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
Hmm - rip out the whole devfs infrastructure and replace it with something which writes tuples of (operation, devname, major, minor) to a socket somewhere, where "operation" is "create", "delete", "online", "offline", etc. Why worry about the complexities of a vfs to handle /dev in the kernel when almost all of it can be done in userland? [ Heh. *now* there'll be some wailing and gnashing of teeth... :-) ] "booting"? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
On Tue, 21 Sep 1999, Mark Newton wrote: Julian Elischer wrote: On Mon, 20 Sep 1999, John-Mark Gurney wrote: one thing that HAS to happen is the fast that some devices CAN'T "appeare" until the devfsd says it can, unless we force a very restrictive permision on all devices (600 or something similar) otherwise we will have security wholes up the wazoo... don't forget about this... a devfsd daemon is definately the way to go... While I sharply disagree, with your assertion, I also point out that if you make such a all-singing-all-dancing devfsd, then you might as well get rid of devfs entirely, and just have devfsd make the devices using normal mknod commands. Hmm - rip out the whole devfs infrastructure and replace it with something which writes tuples of (operation, devname, major, minor) to a socket somewhere, where "operation" is "create", "delete", "online", "offline", etc. Why worry about the complexities of a vfs to handle /dev in the kernel when almost all of it can be done in userland? [ Heh. *now* there'll be some wailing and gnashing of teeth... :-) ] It's always been the main valid alternative to devfs. From teh driver point-of-view it's identical. The make_dev() call that is presently in the drivers simply passes that information up through the socket rather than doing the work directly. The 'tupple' (not really, is it?) would be (name, major, minor, default owner, default perms, type) The daemon would look up the device name in a configuration database where it would find 'exceptions and deviations' as well as default behaviours. This actually solves a few problems that devfs has. It also lses some of the simplicity and reliability that devfs has.. With very little work we could implement both systems since the device interface would be identical. - mark Mark Newton Email: [EMAIL PROTECTED] (W) Network Engineer Email: [EMAIL PROTECTED] (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
On Mon, 20 Sep 1999, Matthew Jacob wrote: Hmm - rip out the whole devfs infrastructure and replace it with something which writes tuples of (operation, devname, major, minor) to a socket somewhere, where "operation" is "create", "delete", "online", "offline", etc. Why worry about the complexities of a vfs to handle /dev in the kernel when almost all of it can be done in userland? [ Heh. *now* there'll be some wailing and gnashing of teeth... :-) ] "booting"? you can make /dev on a small mfs that is automatically mounted, or you can rpepopulate /dev with know boot devices. You don't need /dev to mount root anyhow. In fact you don't need /dev to mount others either as the mount request passes in the device name which could be looked up directly assuming that poul's dev_t cache has the entries already. (result of make_dev()). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
Matthew Jacob wrote: Hmm - rip out the whole devfs infrastructure and replace it with something which writes tuples of (operation, devname, major, minor) to a socket somewhere, where "operation" is "create", "delete", "online", "offline", etc. Why worry about the complexities of a vfs to handle /dev in the kernel when almost all of it can be done in userland? [ Heh. *now* there'll be some wailing and gnashing of teeth... :-) ] "booting"? Not needed - The devfs registration stubs are called during driver initialization which happens at boot time anyway; When the devfsd starts up and reads messages from its socket, it'd get a queue of device instances. I'm envisaging something like /dev/log here; When syslog opens it at boot time, it gets all the log messages that have appeared during initialization. - mark Mark Newton Email: [EMAIL PROTECTED] (W) Network Engineer Email: [EMAIL PROTECTED] (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
Julian Elischer scribbled this message on Sep 20: On Mon, 20 Sep 1999, John-Mark Gurney wrote: one thing that HAS to happen is the fast that some devices CAN'T "appeare" until the devfsd says it can, unless we force a very restrictive permision on all devices (600 or something similar) otherwise we will have security wholes up the wazoo... don't forget about this... a devfsd daemon is definately the way to go... While I sharply disagree, with your assertion, what part exactly? are you saying that we should allow devices to appear that are insecure?? we have two possible ways of dealing with it: a) a daemon "lets" a device appear w/ certain permisions b) a device appears w/ 0600 root:wheel, and the daemon sets the device to proper owner/permissions any other way introduces the problem where you stick in a serial card that contains a sensitive serial console, and someone can "attach" to the device... or many other possible problems... -- John-Mark Gurney Voice: +1 408 975 9651 Cu Networking "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
On Mon, 20 Sep 1999, Julian Elischer wrote: While I sharply disagree, with your assertion, I also point out that if you make such a all-singing-all-dancing devfsd, then you might as well get rid of devfs entirely, and just have devfsd make the devices using normal mknod commands. Since I did not follow the original discussion, maybe this idea has been discussed and discarded, but what about a "translucent" like deal. Basically yu would mount the devfs on top of an existing directrory or filesystem. The underlying contents would "show through" by some set of rules. One rule would be that if a device node existed in the devfs and the real fs, and the device node in the real fs was for the "fake/null whatever you want to call it device", the resulting device node would have the major/minor fron the devfs and the owner/group/permissions from the real fs underneath. Any change to the node would affect the real fs underneath. I could probably expand on this futher if anybody is interested. Brian Beattie| The only problem with [EMAIL PROTECTED] | winning the rat race ... www.aracnet.com/~beattie | in the end you're still a rat To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
"Matthew N. Dodd" wrote: On Mon, 20 Sep 1999, Warner Losh wrote: Yes. That's true. That's why the idea of devfsd is simple, but implementing it well enough for people to be happy with it is much much harder. I think a minimal feature set for the first rev would satisify 90% of those wanting persistence no? ie just tracking permissions and owners for everything, and restoring them to their previous state on startup. This would require that devfsd be started fairly early. Adding a tunable checkpoint interval would be fairly simple. Beyond that it would be a matter of what specific features the 'power users' wanted. This simple behavior would nearly exactly mimic the behavior of a normal filesystem based /dev. Why not to create a simple 'devfs' device ? devfsd can sleep at polling it and devfs device itself can provide hooks in the kernel to register all important events and pass them to devfsd. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
In message [EMAIL PROTECTED] Boris Popov writes: : Why not to create a simple 'devfs' device ? devfsd can sleep at : polling it and devfs device itself can provide hooks in the kernel to : register all important events and pass them to devfsd. That is one option. However, a more general solution would benefit other applications as well. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
On Mon, 20 Sep 1999, Brian Beattie wrote: On Mon, 20 Sep 1999, Julian Elischer wrote: While I sharply disagree, with your assertion, I also point out that if you make such a all-singing-all-dancing devfsd, then you might as well get rid of devfs entirely, and just have devfsd make the devices using normal mknod commands. Since I did not follow the original discussion, maybe this idea has been discussed and discarded, but what about a "translucent" like deal. Basically yu would mount the devfs on top of an existing directrory or filesystem. The underlying contents would "show through" by some set of rules. One rule would be that if a device node existed in the devfs and the real fs, and the device node in the real fs was for the "fake/null whatever you want to call it device", the resulting device node would have the major/minor fron the devfs and the owner/group/permissions from the real fs underneath. Any change to the node would affect the real fs underneath. I could probably expand on this futher if anybody is interested. Basically this is my scheme. Using something like a 'union mount'. I expounded tis as a possibility a few years ago. It is about as close as I can get using a filesystem to do the work. A daemon can do these things easily but has other drawbacks. - the rules are: When mounted with option -layer.. Underlying files do not show through unless the upper one exists. Underlying files supply their ownership/perms but get the major/minor from the devfs layer. The underlying files would be empty regular files (i.e. just an inode). Devfs devices that have no underlying node get their default permissions. Chmod/chown operations create an empty underlying node (if it can, and if the perms change from the default) to hold that info. If mount option -nonew is used only items present at mount time are automatically reflected through. mknod can be used to create new ones but the major an minor will be taken from the devfs blueprint, If the device is not in the devfs the mknod fails. If mount option -empty is used then an empty devfs is mounted. All devices must be created as above. if mount option -clear is used (with -u) then the underlying nodes are all removed. (garbage collection). When the underlying nodes are removed, the upper node still keeps the existing permissions. The action of mv'ing a device doesn't change the name of the underlying node it's associated with.. (it remembers). (and the info) -- to snapshot /dev's permissions and clean all junk underlying files mount -u -clear /dev script that chmods every device to it's present modes/owner Brian Beattie| The only problem with [EMAIL PROTECTED] | winning the rat race ... www.aracnet.com/~beattie | in the end you're still a rat To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
On Tue, 21 Sep 1999, Boris Popov wrote: "Matthew N. Dodd" wrote: Why not to create a simple 'devfs' device ? devfsd can sleep at polling it and devfs device itself can provide hooks in the kernel to register all important events and pass them to devfsd. what supplies the (arbitrarily assigned) major number to that device? (chicken-egg) julian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
Julian Elischer scribbled this message on Sep 20: On Mon, 20 Sep 1999, Brian Beattie wrote: On Mon, 20 Sep 1999, Julian Elischer wrote: While I sharply disagree, with your assertion, I also point out that if you make such a all-singing-all-dancing devfsd, then you might as well get rid of devfs entirely, and just have devfsd make the devices using normal mknod commands. Since I did not follow the original discussion, maybe this idea has been discussed and discarded, but what about a "translucent" like deal. Basically yu would mount the devfs on top of an existing directrory or filesystem. The underlying contents would "show through" by some set of rules. One rule would be that if a device node existed in the devfs and the real fs, and the device node in the real fs was for the "fake/null whatever you want to call it device", the resulting device node would have the major/minor fron the devfs and the owner/group/permissions from the real fs underneath. Any change to the node would affect the real fs underneath. I could probably expand on this futher if anybody is interested. Basically this is my scheme. Using something like a 'union mount'. I expounded tis as a possibility a few years ago. It is about as close as I can get using a filesystem to do the work. A daemon can do these things easily but has other drawbacks. what happens in this case: mount /devfs cd /devfs mv ttyd1 da0c # sure you don't normally do this but you CAN! cd / umount /devfs mount /devfs sorry, that doesn't cut it as you loose your "dynamic" links from the umount to mount, and we are back to the major/minor number to keep track of which device node belongs to which device... -- John-Mark Gurney Voice: +1 408 975 9651 Cu Networking "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
On Mon, 20 Sep 1999, Julian Elischer wrote: one thing that HAS to happen is the fast that some devices CAN'T "appeare" until the devfsd says it can, unless we force a very restrictive permision on all devices (600 or something similar) otherwise we will have security wholes up the wazoo... don't forget about this... a devfsd daemon is definately the way to go... While I sharply disagree, with your assertion, I also point out that if you make such a all-singing-all-dancing devfsd, then you might as well get rid of devfs entirely, and just have devfsd make the devices using normal mknod commands. You guys are going to rerun that whole argument, aren't you? Why don't you just see if there's a way that, if a user wants, they CAN have the devfsd, but otherwise you can do it in rc.conf. You get what you want, they get what they want. You wouldn't be required to write code you hate, just leave in a hook or two, so those folks who want the devfsd can have it. It wouldn't be so darn hard to cooperate, even if you thought the idea was insane, would it? You don't even have to write the code. Chuck Robey| Interests include C programming, Electronics, 213 Lakeside Dr. Apt. T-1 | communications, and signal processing. Greenbelt, MD 20770| I run picnic.mat.net: FreeBSD-current(i386) and (301) 220-2114 | jaunt.mat.net : FreeBSD-current(Alpha) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
On Mon, 20 Sep 1999, John-Mark Gurney wrote: Julian Elischer scribbled this message on Sep 20: On Mon, 20 Sep 1999, Brian Beattie wrote: On Mon, 20 Sep 1999, Julian Elischer wrote: While I sharply disagree, with your assertion, I also point out that if you make such a all-singing-all-dancing devfsd, then you might as well get rid of devfs entirely, and just have devfsd make the devices using normal mknod commands. Since I did not follow the original discussion, maybe this idea has been discussed and discarded, but what about a "translucent" like deal. Basically yu would mount the devfs on top of an existing directrory or filesystem. The underlying contents would "show through" by some set of rules. One rule would be that if a device node existed in the devfs and the real fs, and the device node in the real fs was for the "fake/null whatever you want to call it device", the resulting device node would have the major/minor fron the devfs and the owner/group/permissions from the real fs underneath. Any change to the node would affect the real fs underneath. I could probably expand on this futher if anybody is interested. Basically this is my scheme. Using something like a 'union mount'. I expounded tis as a possibility a few years ago. It is about as close as I can get using a filesystem to do the work. A daemon can do these things easily but has other drawbacks. what happens in this case: mount /devfs cd /devfs mv ttyd1 da0c # sure you don't normally do this but you CAN! da0c is now the name of the vissible alias of ttyd1 cd / umount /devfs mount /devfs ttyd1 is now the name of the visible alias of the device. sorry, that doesn't cut it as you loose your "dynamic" links from the umount to mount, and we are back to the major/minor number to keep track of which device node belongs to which device... no the "original" name is tracked. I don't see your problem the device reverts to it;s original name as it should it remembers any permissions it was given under either name... I think this is good. you may think it's bad. why? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
Julian Elischer scribbled this message on Sep 20: what happens in this case: mount /devfs cd /devfs mv ttyd1 da0c # sure you don't normally do this but you CAN! da0c is now the name of the vissible alias of ttyd1 cd / umount /devfs mount /devfs ttyd1 is now the name of the visible alias of the device. sorry, that doesn't cut it as you loose your "dynamic" links from the umount to mount, and we are back to the major/minor number to keep track of which device node belongs to which device... no the "original" name is tracked. I don't see your problem the device reverts to it;s original name as it should it remembers any permissions it was given under either name... I think this is good. you may think it's bad. why? POLA! if we have persisten permissions and ownership, and we allow renaming, then renaming should also be persistant... after the mount again, da0c either no longer exists, or is no longer ttyd1... which neither is an acceptable solution... -- John-Mark Gurney Voice: +1 408 975 9651 Cu Networking "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
I think devfs is really cool. I don't think it needs to have fancy persistence in order to be useful. Julian, there is a note in the LINT file saying that it doesn't work with MFS. Is this still true? I want to use DEVFS in the BOOTP diskless booting code, which uses MFS heavily. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
On Mon, 20 Sep 1999, John-Mark Gurney wrote: Julian Elischer scribbled this message on Sep 20: what happens in this case: mount /devfs cd /devfs mv ttyd1 da0c # sure you don't normally do this but you CAN! da0c is now the name of the vissible alias of ttyd1 cd / umount /devfs mount /devfs ttyd1 is now the name of the visible alias of the device. sorry, that doesn't cut it as you loose your "dynamic" links from the umount to mount, and we are back to the major/minor number to keep track of which device node belongs to which device... no the "original" name is tracked. I don't see your problem the device reverts to it;s original name as it should it remembers any permissions it was given under either name... I think this is good. you may think it's bad. why? POLA! if we have persisten permissions and ownership, and we allow renaming, then renaming should also be persistant... after the mount again, da0c either no longer exists, or is no longer ttyd1... which neither is an acceptable solution... I think at this stage you've gone overboard.. part of the definition of devfs is that a device shows up on mount with it's canonical name.. On each new mount every time, even if you've mounted it in 10 different places. this is as designed. it is easy to document and easy to understand. this is as 'L' as it gets in POLA in this case.. (L != 0) The only way you could do more would be to make the backing nodes be symlinks, and store the renamed name in the symlink field. I don't think it's worth the extra work. I can provide permssion persistance on a "BY CANONICAL NAME" basis. after that he complexity of the problem goes balistic. julian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
as I explained a few days ago, MFS explodes because it synthesises a device vnode The synthesized vnode is someohow confused as to whether it's a devfs vnode or a UFS vnode. I can't remember the exact problem but it may have something to do with using it as a methid aof getting to teh strategy routine.. I don't remember exaclty, but I think it may be possible to not do that any more. On Mon, 20 Sep 1999, Matthew Dillon wrote: I think devfs is really cool. I don't think it needs to have fancy persistence in order to be useful. Julian, there is a note in the LINT file saying that it doesn't work with MFS. Is this still true? I want to use DEVFS in the BOOTP diskless booting code, which uses MFS heavily. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
On Sat, 18 Sep 1999, Julian Elischer wrote: DEVFS itself works fine however a subsystem it required to be a useful abstraction was vandalised and stripped out by some people who "didn't get it" and it has not yet been replaced by equivalent code. It seems more correct (to me) to state that there was a furious disagreement over whether or not to allow some memory of file permissions in devfs. Since there was never any agreement, DEVFS has smoldered. I think there's general agreement it would be a good thing to have, but that argument over how to keep user configurations must be handled. Saying it was dumped by people who "didn't get it" isn't quite correct, just people who didn't agree with your viewpoint on permissions. It wasn't only your viewpoint, I know there were many other highly qualified folks who agreed with you, but there wasn't much spirit of compromise evinced. Chuck Robey| Interests include C programming, Electronics, 213 Lakeside Dr. Apt. T-1 | communications, and signal processing. Greenbelt, MD 20770| I run picnic.mat.net: FreeBSD-current(i386) and (301) 220-2114 | jaunt.mat.net : FreeBSD-current(Alpha) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
:On Sat, 18 Sep 1999, Julian Elischer wrote: : : DEVFS itself works fine however a subsystem it required to be a useful : abstraction was vandalised and stripped out by some people who "didn't get : it" and it has not yet been replaced by equivalent code. : :It seems more correct (to me) to state that there was a furious :disagreement over whether or not to allow some memory of file permissions :in devfs. Since there was never any agreement, DEVFS has smoldered. I :think there's general agreement it would be a good thing to have, but that :argument over how to keep user configurations must be handled. : :Saying it was dumped by people who "didn't get it" isn't quite correct, :just people who didn't agree with your viewpoint on permissions. It :wasn't only your viewpoint, I know there were many other highly qualified :folks who agreed with you, but there wasn't much spirit of compromise :evinced. : : : :Chuck Robey| Interests include C programming, Electronics, :213 Lakeside Dr. Apt. T-1 | communications, and signal processing. Well, I tried using it months ago but it crashed the machine a lot :-) Those bugs are supposedly fixed now, right? Can I go back to using it? It seems to me that we have to be able to change ownership/modes for DEVFS devices to deal with tty's and pty's properly. Are people arguing over that or are people arguing over whether the changes should be persistent or not? Personally I don't care if they aren't persistent, it's a simple matter to set things up in rc.local. I really want to be able to use DEVFS for my diskless startup code. Right now I have to wave my hands and do some magic to make /dev work right for diskless BOOTP startups. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
On Sun, 19 Sep 1999, Chuck Robey wrote: On Sat, 18 Sep 1999, Julian Elischer wrote: DEVFS itself works fine however a subsystem it required to be a useful abstraction was vandalised and stripped out by some people who "didn't get it" and it has not yet been replaced by equivalent code. It seems more correct (to me) to state that there was a furious disagreement over whether or not to allow some memory of file permissions in devfs. Since there was never any agreement, DEVFS has smoldered. I think there's general agreement it would be a good thing to have, but that argument over how to keep user configurations must be handled. file permissions were not relevant to the code that was ripped out (the stackable disk partitionning layers) (called SLICE). Saying it was dumped by people who "didn't get it" isn't quite correct, just people who didn't agree with your viewpoint on permissions. It wasn't only your viewpoint, I know there were many other highly qualified folks who agreed with you, but there wasn't much spirit of compromise evinced. Chuck Robey| Interests include C programming, Electronics, 213 Lakeside Dr. Apt. T-1 | communications, and signal processing. Greenbelt, MD 20770| I run picnic.mat.net: FreeBSD-current(i386) and (301) 220-2114 | jaunt.mat.net : FreeBSD-current(Alpha) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
as far as I know DEVFS itself is working just fine.. there was some problem with mfs and vn devices at some stage as they used 'dummy' vnodes that were set up to look like device nodes, but mfs and vn tried to use incestuous knowledge which was no longer true and crashed.. I believe that PHKs latest chages may have made it in-necessary for mfs and vn to do that any more.. I'll investigate and get back to you.. julian On Sun, 19 Sep 1999, Matthew Dillon wrote: :On Sat, 18 Sep 1999, Julian Elischer wrote: : : DEVFS itself works fine however a subsystem it required to be a useful : abstraction was vandalised and stripped out by some people who "didn't get : it" and it has not yet been replaced by equivalent code. : :It seems more correct (to me) to state that there was a furious :disagreement over whether or not to allow some memory of file permissions :in devfs. Since there was never any agreement, DEVFS has smoldered. I :think there's general agreement it would be a good thing to have, but that :argument over how to keep user configurations must be handled. : :Saying it was dumped by people who "didn't get it" isn't quite correct, :just people who didn't agree with your viewpoint on permissions. It :wasn't only your viewpoint, I know there were many other highly qualified :folks who agreed with you, but there wasn't much spirit of compromise :evinced. : : : :Chuck Robey| Interests include C programming, Electronics, :213 Lakeside Dr. Apt. T-1 | communications, and signal processing. Well, I tried using it months ago but it crashed the machine a lot :-) Those bugs are supposedly fixed now, right? Can I go back to using it? It seems to me that we have to be able to change ownership/modes for DEVFS devices to deal with tty's and pty's properly. Are people arguing over that or are people arguing over whether the changes should be persistent or not? Personally I don't care if they aren't persistent, it's a simple matter to set things up in rc.local. I really want to be able to use DEVFS for my diskless startup code. Right now I have to wave my hands and do some magic to make /dev work right for diskless BOOTP startups. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
On Sun, 19 Sep 1999, Julian Elischer wrote: On Sun, 19 Sep 1999, Chuck Robey wrote: On Sat, 18 Sep 1999, Julian Elischer wrote: DEVFS itself works fine however a subsystem it required to be a useful abstraction was vandalised and stripped out by some people who "didn't get it" and it has not yet been replaced by equivalent code. It seems more correct (to me) to state that there was a furious disagreement over whether or not to allow some memory of file permissions in devfs. Since there was never any agreement, DEVFS has smoldered. I think there's general agreement it would be a good thing to have, but that argument over how to keep user configurations must be handled. file permissions were not relevant to the code that was ripped out (the stackable disk partitionning layers) (called SLICE). But it was to the subject on the Subject: line, Julian. We know what side you're on, but there are 2 sides to the argument. Isn't there some way that it can be set up to *optionally* have permission persistence? If you would get past that point, then all the political problems that remain are solvable. Whatever, let's please not get into an argument over persistence, it's in the archives. Chuck Robey| Interests include C programming, Electronics, 213 Lakeside Dr. Apt. T-1 | communications, and signal processing. Greenbelt, MD 20770| I run picnic.mat.net: FreeBSD-current(i386) and (301) 220-2114 | jaunt.mat.net : FreeBSD-current(Alpha) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
:you're on, but there are 2 sides to the argument. Isn't there some way :that it can be set up to *optionally* have permission persistence? : :If you would get past that point, then all the political problems that :remain are solvable. : :Whatever, let's please not get into an argument over persistence, it's in :the archives. : : :Chuck Robey| Interests include C programming, Electronics, Personally speaking I don't see how permission persistence could possibly be implemented within DEVFS itself without a huge amount of work. I'm not sure it would be appropriate to implement it there anyhow when it is so easy to just make the necessary changes in rc.local. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
On Sun, 19 Sep 1999, Chuck Robey wrote: But it was to the subject on the Subject: line, Julian. We know what side you're on, but there are 2 sides to the argument. Isn't there some way that it can be set up to *optionally* have permission persistence? Seems like a devfsd using the file monitoring hooks would work; you'd only update the persistent store if you were running devfsd. devfsd would read the store and init /dev with the contents. I think the only issue that would involve thinking would be whiteouts (and the actual devfsd code of course.) -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
DEVFS is an experimental idea. Both FreeBSD and Linux are experimenting with the concept of a filesystem type that is used by the kernel to export it's view of what devices are present and capable of being used. in -current, the devfsext.h file is no longer required as the functions it defines are no longer directly called by the driver (I need to fix the example drivers) and instead, a function "make_device()" is called . This is done regradless of whether DEVFS is compiled in, and this function then calls the DEVFS functions if DEVFS is required. The theory is that DEVFS allows totally dynamic registration of devices. This is required in several cases.. 1/ many new device drivers, are written and co-ordinating/assigning major numbers becomes infeasible.. (not happenned yet, but might in the future) 2/ Subdividing devices for sub functions may need to be arbitrary in form, and it may be infeasible to assign minor numbers in a predefinable manner... Think of a disk concatination scheme which is doen in the same framework as a disk partition scheme. Is a BSD partition within a dos partition the same minor number ans a dos partition within a BSD partition? And what minor number is a partition of an concattinated drive made from sub partitions of 3 differnt drives, one of which is divided using DOS partitions and the other using a BSD partiton within a DOS partition? his is presently done with a major hack of assigning a different major number to the concatinated device. 3/ NFS mounting a / filesystem from (say) NT which can NFS export a filesystem but cannot export device nodes means that the local system needs to provide it's own /dev. (this is getting to be less of a problem) Or, getting a /dev/from Linux, where all the minors are wrong for BSD and we need to get our own from "somewhere". DEVFS itself works fine however a subsystem it required to be a useful abstraction was vandalised and stripped out by some people who "didn't get it" and it has not yet been replaced by equivalent code. That functionality is required if you want to mount several local filesystems. However the current devfs is quite capable of being used in NFS mounted (netbooted) scenareos. On Sat, 18 Sep 1999, Wayne Cuddy wrote: In the examples device drivers I see the inclusion of devfsext.h. I read the README in the devfs directory but I am still a little unsure what devfs would be used for. Can anyone give me some examples here. Is there any more information pertaining to devfs? Thanks in advance, Wayne To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
For some alternative perspective- DEVFS has been around in many systems for a long time. Solaris attempted to go this way, but has taken a decade to move out a year's worth of progress. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
On Sat, Sep 18, 1999, Julian Elischer wrote: DEVFS is an experimental idea. I must also say that DEVFS is an excellent idea. I honestly didn't really understand it until recently, though I've heard about it for a while. -- |Chris Costello [EMAIL PROTECTED] |Watch out for off-by-one errors. `-- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
On Sat, Sep 18, 1999, Julian Elischer wrote: DEVFS is an experimental idea. I must also say that DEVFS is an excellent idea. It's a marvelous idea, and is going to be very necessary when large Fibre fabrics become more common. The problems of making it stable and meaningful are enormous though. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what is devfs?
DEVFS is an experimental idea. Both FreeBSD and Linux are experimenting with the concept of a filesystem type that is used by the kernel to export it's view of what devices are present and capable of being used. in -current, the devfsext.h file is no longer required as the functions it defines are no longer directly called by the driver (I need to fix the example drivers) and instead, a function make_device() is called . This is done regradless of whether DEVFS is compiled in, and this function then calls the DEVFS functions if DEVFS is required. The theory is that DEVFS allows totally dynamic registration of devices. This is required in several cases.. 1/ many new device drivers, are written and co-ordinating/assigning major numbers becomes infeasible.. (not happenned yet, but might in the future) 2/ Subdividing devices for sub functions may need to be arbitrary in form, and it may be infeasible to assign minor numbers in a predefinable manner... Think of a disk concatination scheme which is doen in the same framework as a disk partition scheme. Is a BSD partition within a dos partition the same minor number ans a dos partition within a BSD partition? And what minor number is a partition of an concattinated drive made from sub partitions of 3 differnt drives, one of which is divided using DOS partitions and the other using a BSD partiton within a DOS partition? his is presently done with a major hack of assigning a different major number to the concatinated device. 3/ NFS mounting a / filesystem from (say) NT which can NFS export a filesystem but cannot export device nodes means that the local system needs to provide it's own /dev. (this is getting to be less of a problem) Or, getting a /dev/from Linux, where all the minors are wrong for BSD and we need to get our own from somewhere. DEVFS itself works fine however a subsystem it required to be a useful abstraction was vandalised and stripped out by some people who didn't get it and it has not yet been replaced by equivalent code. That functionality is required if you want to mount several local filesystems. However the current devfs is quite capable of being used in NFS mounted (netbooted) scenareos. On Sat, 18 Sep 1999, Wayne Cuddy wrote: In the examples device drivers I see the inclusion of devfsext.h. I read the README in the devfs directory but I am still a little unsure what devfs would be used for. Can anyone give me some examples here. Is there any more information pertaining to devfs? Thanks in advance, Wayne To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: what is devfs?
For some alternative perspective- DEVFS has been around in many systems for a long time. Solaris attempted to go this way, but has taken a decade to move out a year's worth of progress. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: what is devfs?
On Sat, Sep 18, 1999, Julian Elischer wrote: DEVFS is an experimental idea. I must also say that DEVFS is an excellent idea. I honestly didn't really understand it until recently, though I've heard about it for a while. -- |Chris Costello ch...@calldei.com |Watch out for off-by-one errors. `-- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: what is devfs?
On Sat, Sep 18, 1999, Julian Elischer wrote: DEVFS is an experimental idea. I must also say that DEVFS is an excellent idea. It's a marvelous idea, and is going to be very necessary when large Fibre fabrics become more common. The problems of making it stable and meaningful are enormous though. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
