Re: DEVFS, the time has come...
I agree.. and same thing goes for Ethernet drivers. I actually like the way Linux always has eth0, eth1, ... (which we could Yeagh... what is wrong with ed0, de0, fxp0 etc that needs changing? Is this just a matter of taste or is there more to it? I for one don't see any advantage in eth[0-9] style device naming. I can give you one example. We run a FreeBSD box here which receives all of the traffic (port mirroring) from some Ethernet switches. On the FreeBSD box, we run nnstat, tcpdump etc. for monitoring purposes. Recently I changed some of the DEC 21x4x based cards on this box to Intel cards. Thus the interface names changed from deN to fxpN. This meant we had to update a bunch of Perl and shell scripts. It would have been much nicer (no need to update) if the interfaces were simply named ethN. Personally, I'd also prefer to have IDE disks named daN, but that's another matter... Steinar Haug, Nethelp consulting, sth...@nethelp.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
On Thu, 28 Jan 1999, Harlan Stenn wrote: Also the eth[0..x] thing means you can replace your ethernet card with a new one of a different type without having to look through your config code for references to ed0 or whatever. Just to ask, what happens when the probe order changes and your multiple NICs start popping up on the wrong eth port? This may be *much* more difficult when one of several cards die (how do you know which one broke?) and then you replace it and discover the new probe order is different... Or will be be able to wire them down in the config file (which will at least address part of the problem)? If we did this, there would obviously have to be some kind of wiring system. The same problem exists in a much smaller way for machines with more that one of the same type of card. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
On Thu, 28 Jan 1999, Leif Neland wrote: On Wed, 27 Jan 1999, Archie Cobbs wrote: Doug Rabson writes: And another thing. Why can't we use a non-driver-specific name for the disk? Most users simply don't care whether the driver was fd, wfd, wd or anything. They just want to get to their files without any fuss. I agree.. and same thing goes for Ethernet drivers. I actually like the way Linux always has eth0, eth1, ... (which we could do using netgraph, with some work). Just symlink eth0 to which card you like, just as /dev/mixer happens to be a symlink to /dev/mixer1 on my system. Unfortunately network devices aren't represented in /dev on BSD systems. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
From: Wilko Bulte wi...@yedi.iaf.nl Date: Wed, 27 Jan 1999 23:12:18 +0100 (CET) Yeagh... what is wrong with ed0, de0, fxp0 etc that needs changing? Is this just a matter of taste or is there more to it? I for one don't see any advantage in eth[0-9] style device naming. It's a matter of whether you want the name to reflect the implementation vs. the function. For someone involved in the details of the implementation, being (acutely!) aware of those details can be very important. For someone who merely wants to have a certain physical port on the machine connected to a particular network, that level of detail is not always appropriate. It depends on your focus. Cheers, david -- David Wolfskill UNIX System Administrator d...@whistle.comvoice: (650) 577-7158 pager: (650) 371-4621 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
As sth...@nethelp.no wrote... I agree.. and same thing goes for Ethernet drivers. I actually like the way Linux always has eth0, eth1, ... (which we could Yeagh... what is wrong with ed0, de0, fxp0 etc that needs changing? Is this just a matter of taste or is there more to it? I for one don't see any advantage in eth[0-9] style device naming. I can give you one example. We run a FreeBSD box here which receives all of the traffic (port mirroring) from some Ethernet switches. On the FreeBSD box, we run nnstat, tcpdump etc. for monitoring purposes. Recently I changed some of the DEC 21x4x based cards on this box to Intel cards. Thus the interface names changed from deN to fxpN. This meant we had to update a bunch of Perl and shell scripts. It would have been much nicer (no need to update) if the interfaces were simply named ethN. Hmmm. Well I happen to like the concept of being able to tell straight away what device I'm talking to. eth# style naming does not allow that. But I can understand that other people might feel otherwise. Wilko _ __ | / o / / _ Bulteemail: wi...@yedi.iaf.nl |/|/ / / /( (_) Arnhem, The Netherlands WWW : http://www.tcja.nl __ Powered by FreeBSD __ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
As Daniel O'Connor wrote... On 27-Jan-99 Wilko Bulte wrote: I agree.. and same thing goes for Ethernet drivers. I actually like the way Linux always has eth0, eth1, ... (which we could Yeagh... what is wrong with ed0, de0, fxp0 etc that needs changing? Is this just a matter of taste or is there more to it? I for one don't see any advantage in eth[0-9] style device naming. Well, for one its sucks trying to get newbies to work out what their network card is called.. Not true IMO. You still need to know what hardware you have before you can build your own kernels etc etc. Also the eth[0..x] thing means you can replace your ethernet card with a new one of a different type without having to look through your config code for references to ed0 or whatever. True. Another thing.. we get to be more Linux like, which is a good thing, right? *duck* Ducking does not help with todays laser-guided precision ammo ;-) ;-) And to answer your question: the day FreeBSD aims to become like Linux I'm likely to install NT. Wilko _ __ | / o / / _ Bulteemail: wi...@yedi.iaf.nl |/|/ / / /( (_) Arnhem, The Netherlands WWW : http://www.tcja.nl __ Powered by FreeBSD __ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
Not true IMO. You still need to know what hardware you have before you can build your own kernels etc etc. Also the eth[0..x] thing means you can replace your ethernet card with a new one of a different type without having to look through your config code for references to ed0 or whatever. True. There's no reason why the devfs code couldn't create the equivalent of symbolic links in its file system so that ed0 and eth0 show up. Yes, I know, this opens up a can of worms when new hardware is added and suddenly the probe order changes such that a newbie finds that eth0 is no longer what he/she/it thought it was going to be. But it's a start. -scooter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
As David Wolfskill wrote... From: Wilko Bulte wi...@yedi.iaf.nl Date: Wed, 27 Jan 1999 23:12:18 +0100 (CET) Yeagh... what is wrong with ed0, de0, fxp0 etc that needs changing? Is this just a matter of taste or is there more to it? I for one don't see any advantage in eth[0-9] style device naming. It's a matter of whether you want the name to reflect the implementation vs. the function. For someone involved in the details of the implementation, being (acutely!) aware of those details can be very important. Guilty your honor ;-) My daily work is in supporting customers, so I can really do without mapping 'convenient names' to physical stuff. For an example: look at the Solaris symlink jungle for device naming. For someone who merely wants to have a certain physical port on the machine connected to a particular network, that level of detail is not always appropriate. It depends on your focus. Agreed. Wilko _ __ | / o / / _ Bulteemail: wi...@yedi.iaf.nl |/|/ / / /( (_) Arnhem, The Netherlands WWW : http://www.tcja.nl __ Powered by FreeBSD __ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
On Thu, 28 Jan 1999 sth...@nethelp.no wrote: I agree.. and same thing goes for Ethernet drivers. I actually like the way Linux always has eth0, eth1, ... (which we could Yeagh... what is wrong with ed0, de0, fxp0 etc that needs changing? Is this just a matter of taste or is there more to it? I for one don't see any advantage in eth[0-9] style device naming. I can give you one example. We run a FreeBSD box here which receives all of the traffic (port mirroring) from some Ethernet switches. On the FreeBSD box, we run nnstat, tcpdump etc. for monitoring purposes. Recently I changed some of the DEC 21x4x based cards on this box to Intel cards. Thus the interface names changed from deN to fxpN. This meant we had to update a bunch of Perl and shell scripts. It would have been much nicer (no need to update) if the interfaces were simply named ethN. That's why you don't hard code the interfaces into all the scripts. Instead source a file that gives the definitions ala rc.conf. Personally, I'd also prefer to have IDE disks named daN, but that's another matter... :) -Alfred To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
Wilko Bulte wrote: Well, for one its sucks trying to get newbies to work out what their network card is called.. Not true IMO. You still need to know what hardware you have before you can build your own kernels etc etc. Yes, this is true, but when they have just installed then its true :) Also, hopefully when we have the autodetection of hardware and loading KLD's for network cards etc, this would be so much nicer IMHO.. Just 'tidier'.. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andnew Tanenbaum To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
On Thu, 28 Jan 1999, Kenneth D. Merry wrote: Just symlink eth0 to which card you like, just as /dev/mixer happens to be a symlink to /dev/mixer1 on my system. How are you going to do that, when network drivers don't have device nodes? Minor point :-) Sorry, I missed that. Leif To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: DEVFS, the time has come...
On Tue, 26 Jan 1999 p...@originative.co.uk wrote: -Original Message- From: Poul-Henning Kamp [mailto:p...@critter.freebsd.dk] Sent: Tuesday, January 26, 1999 10:41 AM To: Doug Rabson Cc: Archie Cobbs; Maxim Sobolev; curr...@freebsd.org; Julian Elischer Subject: Re: DEVFS, the time has come... No, it doesn't have to be SLICE. In particular, if we're going the SLICE way, it should be done right, and Julians SLICE code didn't do that. (I know, I spent close to 6 months prototyping the concept and julian had my code to work from). Wouldn't it be possible to fit this into the device system? If we treat disks as devices and partition types as drivers, most of the boring work of matching drivers to devices and keeping lists and trees of objects will happen automatically. Well, as long as you remember that it is not a strict hierarchy: I could slice two disks, mirror the slices and concatenate the mirrors if I wanted to. Where does this happen though? If we go with Doug's idea (which seems quite neat), then the device subsystem will present devices for each of the slices/partitions that the low level disk handling code finds during the probe phase. The mirroring of slices and subsequent concatenation of the mirrors, or any other combination of slice munging that might take place happens later doesn't it, using something like vinum. If so then can't vinum become responsible for modifying the device view, i.e. if it creates a concatenated partition then it could remove the two low level slice devices and create a new disk device that represents the concatenated area. You might not want to remove the low level devices or it could be a vinum configuration option. If something like vinum doesn't exist then you're not going to be doing any mirroring or concatenation and Doug's solution would be fine for creating the device nodes needed to represent the actual layout of the disks, as opposed to a view of the disks that might be created by vinum et al. Poul is correct that this stuff is fairly easy. I did a sketch implementation of a simple disk interface with drivers for mbr and bsd labels and it seems to be the right direction to take. There are issues I didn't bother to tackle (device naming, geometry) but since Julian's slice code had this functionality and it is well understood, I don't think there would be problems. As far as ccd and vinum go, I thought that ccd would pick up disk partitions from the leaves of the slice tree and do its thing to create a virtual disk. This virtual disk would then be fed back into the disk probing system to spawn another partition tree. Vinum could do something similar but I think it has its own advanced ideas on partitioning. The system could be easily extended to probing the filesystem type. It would be really nice to automount partitions from removable media as it is inserted. I think the requirement that a user must use (root privileged) commands just to get to the files on a floppy/zip is ridiculous for someone used to Win32 systems. Perhaps the nebulous devd could be coerced into managing removable media as well (with configuration options for mounting, e.g. nosuid). And another thing. Why can't we use a non-driver-specific name for the disk? Most users simply don't care whether the driver was fd, wfd, wd or anything. They just want to get to their files without any fuss. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
Doug Rabson writes: And another thing. Why can't we use a non-driver-specific name for the disk? Most users simply don't care whether the driver was fd, wfd, wd or anything. They just want to get to their files without any fuss. I agree.. and same thing goes for Ethernet drivers. I actually like the way Linux always has eth0, eth1, ... (which we could do using netgraph, with some work). -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
On 27-Jan-99 Archie Cobbs wrote: I agree.. and same thing goes for Ethernet drivers. I actually like the way Linux always has eth0, eth1, ... (which we could do using netgraph, with some work). Me too :) Of course you'd have to be able to do things like 'wire down' your ethernet card etc.. But the idea is nice IMHO :) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
Daniel O'Connor writes: On 27-Jan-99 Archie Cobbs wrote: I agree.. and same thing goes for Ethernet drivers. I actually like the way Linux always has eth0, eth1, ... (which we could do using netgraph, with some work). Me too :) Of course you'd have to be able to do things like 'wire down' your ethernet card etc.. But the idea is nice IMHO :) That would be easy part! :-) Something like this... $ ngctl mkpeer ed0: eth_iface upstream downstream -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
On 28-Jan-99 Archie Cobbs wrote: That would be easy part! :-) Something like this... $ ngctl mkpeer ed0: eth_iface upstream downstream Heh.. It would be nice if it was automagic though.. (Where's my kernel config option :) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
Daniel O'Connor writes: On 28-Jan-99 Archie Cobbs wrote: That would be easy part! :-) Something like this... $ ngctl mkpeer ed0: eth_iface upstream downstream Heh.. It would be nice if it was automagic though.. Well, if it's automatic then you can't necessarily wire it down the way you want to.. you can't have both at the same time. Anyway, it's not automatic now either: network_interfaces=lo0 ed0 # List of network interfaces (lo0 is loopback). ifconfig_lo0=inet 127.0.0.1 # default loopback device configuration. ifconfig_ed0=inet 192.168.1.1 ...etc... -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
On 28-Jan-99 Archie Cobbs wrote: Well, if it's automatic then you can't necessarily wire it down the way you want to.. you can't have both at the same time. Anyway, it's not automatic now either: network_interfaces=lo0 ed0 # List of network interfaces (lo0 is loopback). ifconfig_lo0=inet 127.0.0.1 # default loopback device configuration. ifconfig_ed0=inet 192.168.1.1 ...etc... I suppose thats true.. So whens do the patches for it arrive? ;) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
Daniel O'Connor writes: Anyway, it's not automatic now either: network_interfaces=lo0 ed0 # List of network interfaces (lo0 is loopback). ifconfig_lo0=inet 127.0.0.1 # default loopback device configuration. ifconfig_ed0=inet 192.168.1.1 ...etc... I suppose thats true.. So whens do the patches for it arrive? ;) I think Julian is going to create some patches to if_ethersubr.c so that all your Ethernet interfaces appear as netgraph nodes. Then you can do some fun things.. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
As Archie Cobbs wrote... Doug Rabson writes: And another thing. Why can't we use a non-driver-specific name for the disk? Most users simply don't care whether the driver was fd, wfd, wd or anything. They just want to get to their files without any fuss. I agree.. and same thing goes for Ethernet drivers. I actually like the way Linux always has eth0, eth1, ... (which we could Yeagh... what is wrong with ed0, de0, fxp0 etc that needs changing? Is this just a matter of taste or is there more to it? I for one don't see any advantage in eth[0-9] style device naming. Wilko _ __ | / o / / _ Bulteemail: wi...@yedi.iaf.nl |/|/ / / /( (_) Arnhem, The Netherlands WWW : http://www.tcja.nl __ Powered by FreeBSD __ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
On 27-Jan-99 Wilko Bulte wrote: I agree.. and same thing goes for Ethernet drivers. I actually like the way Linux always has eth0, eth1, ... (which we could Yeagh... what is wrong with ed0, de0, fxp0 etc that needs changing? Is this just a matter of taste or is there more to it? I for one don't see any advantage in eth[0-9] style device naming. Well, for one its sucks trying to get newbies to work out what their network card is called.. Also the eth[0..x] thing means you can replace your ethernet card with a new one of a different type without having to look through your config code for references to ed0 or whatever. Another thing.. we get to be more Linux like, which is a good thing, right? *duck* --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
Also the eth[0..x] thing means you can replace your ethernet card with a new one of a different type without having to look through your config code for references to ed0 or whatever. Just to ask, what happens when the probe order changes and your multiple NICs start popping up on the wrong eth port? This may be *much* more difficult when one of several cards die (how do you know which one broke?) and then you replace it and discover the new probe order is different... Or will be be able to wire them down in the config file (which will at least address part of the problem)? H To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
On 28-Jan-99 Harlan Stenn wrote: code for references to ed0 or whatever. Just to ask, what happens when the probe order changes and your multiple NICs start popping up on the wrong eth port? Thats why I mentioned wiring them down a la SCSI. Or will be be able to wire them down in the config file (which will at least address part of the problem)? IMHO it would address ALL of the problem.. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
Harlan Stenn writes: Also the eth[0..x] thing means you can replace your ethernet card with a new one of a different type without having to look through your config code for references to ed0 or whatever. Just to ask, what happens when the probe order changes and your multiple NICs start popping up on the wrong eth port? It wouldn't be based on probe order, unless you wanted it to be fully automatic (read: newbies). The rest of us would use an explict rc.network (or whatever) configuration that linked up specific ethernet drivers with interfaces. I think Solaris (?) requires you to do this, it's called plumbing your interfaces or something (according to Julian). -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
On Wed, 27 Jan 1999, Archie Cobbs wrote: Doug Rabson writes: And another thing. Why can't we use a non-driver-specific name for the disk? Most users simply don't care whether the driver was fd, wfd, wd or anything. They just want to get to their files without any fuss. I agree.. and same thing goes for Ethernet drivers. I actually like the way Linux always has eth0, eth1, ... (which we could do using netgraph, with some work). Just symlink eth0 to which card you like, just as /dev/mixer happens to be a symlink to /dev/mixer1 on my system. Leif To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
Leif Neland wrote... On Wed, 27 Jan 1999, Archie Cobbs wrote: Doug Rabson writes: And another thing. Why can't we use a non-driver-specific name for the disk? Most users simply don't care whether the driver was fd, wfd, wd or anything. They just want to get to their files without any fuss. I agree.. and same thing goes for Ethernet drivers. I actually like the way Linux always has eth0, eth1, ... (which we could do using netgraph, with some work). Just symlink eth0 to which card you like, just as /dev/mixer happens to be a symlink to /dev/mixer1 on my system. How are you going to do that, when network drivers don't have device nodes? Ken -- Kenneth Merry k...@plutotech.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
I think Solaris (?) requires you to do this, it's called plumbing your interfaces or something (according to Julian). Solaris requires interface plumbing as the result of STREAMS; you have to push IP on top of the interface driver. For all intents and purposes, the device name identifies a particular driver (i.e. le, qe, hme, fa, c). The number identifies an instance of the device which depends on probe order. [*] Fortunately, the BSD world avoided this particular form of brain damage, thank insert deity name here! OTOH, as ph--ked as STREAMS happens to be, it does have a certain appeal wrt dynamically building and tearing down network stacks. The ATT model just didn't have IP in mind when it was designed. -scooter [*] I'd written a hacked version of ifconfig based on the output of 'truss' and managed to get it right in a limited way, as in ifconfig only plumbs IP on top of devices. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
On Wed, 27 Jan 1999, Archie Cobbs wrote: Harlan Stenn writes: Also the eth[0..x] thing means you can replace your ethernet card with a new one of a different type without having to look through your config code for references to ed0 or whatever. Just to ask, what happens when the probe order changes and your multiple NICs start popping up on the wrong eth port? It wouldn't be based on probe order, unless you wanted it to be fully automatic (read: newbies). The rest of us would use an explict rc.network (or whatever) configuration that linked up specific ethernet drivers with interfaces. I think Solaris (?) requires you to do this, it's called plumbing your interfaces or something (according to Julian). please god no... i spent a long while figuring that out the first time i played with a solaris box, it's NOT intuative. i like the idea of aliases and wiring aliases to real names: xl0 - eth0 fxp0 - eth1 ... thanks, -Alfred To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
In message 199901260451.uaa23...@bubba.whistle.com, Archie Cobbs writes: Maxim Sobolev writes: Can you point all people (and me of course) who want to test DEVFS to some common information about DEVFS (usage, possible advantages/disadvantages etc. I think some FAQ or so will be nice. It's really will help us to go further with this issue. I agree.. and I've bugged Julian to put something together... Basically, there are a few things that need to be done to get DEVFS into the 'mainstream'... and this includes SLICE. No, it doesn't have to be SLICE. In particular, if we're going the SLICE way, it should be done right, and Julians SLICE code didn't do that. (I know, I spent close to 6 months prototyping the concept and julian had my code to work from). -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
On Tue, 26 Jan 1999, Poul-Henning Kamp wrote: In message 199901260451.uaa23...@bubba.whistle.com, Archie Cobbs writes: Maxim Sobolev writes: Can you point all people (and me of course) who want to test DEVFS to some common information about DEVFS (usage, possible advantages/disadvantages etc. I think some FAQ or so will be nice. It's really will help us to go further with this issue. I agree.. and I've bugged Julian to put something together... Basically, there are a few things that need to be done to get DEVFS into the 'mainstream'... and this includes SLICE. No, it doesn't have to be SLICE. In particular, if we're going the SLICE way, it should be done right, and Julians SLICE code didn't do that. (I know, I spent close to 6 months prototyping the concept and julian had my code to work from). Wouldn't it be possible to fit this into the device system? If we treat disks as devices and partition types as drivers, most of the boring work of matching drivers to devices and keeping lists and trees of objects will happen automatically. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
No, it doesn't have to be SLICE. In particular, if we're going the SLICE way, it should be done right, and Julians SLICE code didn't do that. (I know, I spent close to 6 months prototyping the concept and julian had my code to work from). Wouldn't it be possible to fit this into the device system? If we treat disks as devices and partition types as drivers, most of the boring work of matching drivers to devices and keeping lists and trees of objects will happen automatically. Well, as long as you remember that it is not a strict hierarchy: I could slice two disks, mirror the slices and concatenate the mirrors if I wanted to. It's not tricky to get it right, once you know where the pitfalls are, the trick is to get it right AND make it elegant. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: DEVFS, the time has come...
-Original Message- From: Poul-Henning Kamp [mailto:p...@critter.freebsd.dk] Sent: Tuesday, January 26, 1999 10:41 AM To: Doug Rabson Cc: Archie Cobbs; Maxim Sobolev; curr...@freebsd.org; Julian Elischer Subject: Re: DEVFS, the time has come... No, it doesn't have to be SLICE. In particular, if we're going the SLICE way, it should be done right, and Julians SLICE code didn't do that. (I know, I spent close to 6 months prototyping the concept and julian had my code to work from). Wouldn't it be possible to fit this into the device system? If we treat disks as devices and partition types as drivers, most of the boring work of matching drivers to devices and keeping lists and trees of objects will happen automatically. Well, as long as you remember that it is not a strict hierarchy: I could slice two disks, mirror the slices and concatenate the mirrors if I wanted to. Where does this happen though? If we go with Doug's idea (which seems quite neat), then the device subsystem will present devices for each of the slices/partitions that the low level disk handling code finds during the probe phase. The mirroring of slices and subsequent concatenation of the mirrors, or any other combination of slice munging that might take place happens later doesn't it, using something like vinum. If so then can't vinum become responsible for modifying the device view, i.e. if it creates a concatenated partition then it could remove the two low level slice devices and create a new disk device that represents the concatenated area. You might not want to remove the low level devices or it could be a vinum configuration option. If something like vinum doesn't exist then you're not going to be doing any mirroring or concatenation and Doug's solution would be fine for creating the device nodes needed to represent the actual layout of the disks, as opposed to a view of the disks that might be created by vinum et al. Paul. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
Wouldn't it be possible to fit this into the device system? If we treat disks as devices and partition types as drivers, most of the boring work of matching drivers to devices and keeping lists and trees of objects will happen automatically. Well, as long as you remember that it is not a strict hierarchy: I could slice two disks, mirror the slices and concatenate the mirrors if I wanted to. Where does this happen though? If we go with Doug's idea (which seems quite neat), then the device subsystem will present devices for each of the slices/partitions that the low level disk handling code finds during the probe phase. Step back one step, and realize that handling fdisk or disklabel partitioning is just another geometry translation, just like mirroring/striping/concatenating/raid-%d/copy-on-write and so on. (The only magic about them is that we're more used to them.) Vinum would fit right into this. The major problem is the struct buf which is too bloated to work with for iorequests. There are some boot time issues too but they are more a DEVFS kind of thing than a SLICE/GEOMETRY thing. As I said, doing it generally is easy, all in all. If there is interest I can try to find my design-notes for it. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
[.] So I'd like to make another attempt to get agreement on the next step here, so that *something* can happen. We need to get more people using DEVFS, so we can gain some experience feedback. I don't think DEVFS has any issues that are not surmountable. However, at some point you must take the next step. [.] Comments?? The issue here is not whether this proposal is a sufficient *final* incarnation of DEVFS, but whether it's a sufficient next step.. How functional is DEVFS at the moment ? I was using it before the SLICE stuff was torn out, and gave up at that point. Without SLICE, does DEVFS create the devices with the same major/minor numbers as normal ? Without SLICE, is it necessary to have a /dev to boot off ? FWIW, I'm 100% behind DEVFS as none of the pitfalls affect me :-I -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com -- Brian br...@awfulhak.org br...@freebsd.org br...@openbsd.org http://www.Awfulhak.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
Dear Archie, Can you point all people (and me of course) who want to test DEVFS to some common information about DEVFS (usage, possible advantages/disadvantages etc.)? I think some FAQ or so will be nice. It's really will help us to go further with this issue. Sincerely, Maxim Archie Cobbs wrote: This email was a few weeks ago, and there was a lively debate, then Julian sent an email listing some issues/requirements, and then the thread kindof died and now we're back to where we were before, which is not any further on.. [Skipped] Comments?? The issue here is not whether this proposal is a sufficient *final* incarnation of DEVFS, but whether it's a sufficient next step.. -Archie ___ Archie Cobbs?? *?? Whistle Communications, Inc.? *?? http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
yo, brian, are you on 'net'? have you had a look at the netgraph stuff? particularly the kernel nodes that we use in conjuntion with mpd, and the usserland modules of mpd that we use with it? On Mon, 25 Jan 1999, Brian Somers wrote: [.] So I'd like to make another attempt to get agreement on the next step here, so that *something* can happen. We need to get more people using DEVFS, so we can gain some experience feedback. I don't think DEVFS has any issues that are not surmountable. However, at some point you must take the next step. [.] Comments?? The issue here is not whether this proposal is a sufficient *final* incarnation of DEVFS, but whether it's a sufficient next step.. How functional is DEVFS at the moment ? I was using it before the SLICE stuff was torn out, and gave up at that point. Without SLICE, does DEVFS create the devices with the same major/minor numbers as normal ? Without SLICE, is it necessary to have a /dev to boot off ? FWIW, I'm 100% behind DEVFS as none of the pitfalls affect me :-I -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com -- Brian br...@awfulhak.org br...@freebsd.org br...@openbsd.org http://www.Awfulhak.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
Brian Somers writes: So I'd like to make another attempt to get agreement on the next step here, so that *something* can happen. We need to get more people using DEVFS, so we can gain some experience feedback. I don't think DEVFS has any issues that are not surmountable. However, at some point you must take the next step. [.] Comments?? The issue here is not whether this proposal is a sufficient *final* incarnation of DEVFS, but whether it's a sufficient next step.. How functional is DEVFS at the moment ? I was using it before the SLICE stuff was torn out, and gave up at that point. Without SLICE, does DEVFS create the devices with the same major/minor numbers as normal ? Without SLICE, is it necessary to have a /dev to boot off ? You would have to ask Julian this question. However, my impression is that there are a couple of things that are broken, but nothing too serious that it can't be fixed/updated relatively quickly. Julian, is that accurrate? What about the MFS problem -- how hard is that to fix? I.E. What's required to get DEVFS to the point where 'the masses' (including me :-) can use it with minimal pain/disruption? -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
yo, brian, are you on 'net'? have you had a look at the netgraph stuff? particularly the kernel nodes that we use in conjuntion with mpd, and the usserland modules of mpd that we use with it? Eh, dunno :-/ What's netgraph (it rings bells - have you mentioned it before ?) ? -- Brian br...@awfulhak.org br...@freebsd.org br...@openbsd.org http://www.Awfulhak.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
Brian Somers writes: yo, brian, are you on 'net'? have you had a look at the netgraph stuff? particularly the kernel nodes that we use in conjuntion with mpd, and the usserland modules of mpd that we use with it? Eh, dunno :-/ What's netgraph (it rings bells - have you mentioned it before ?) ? It was announced on freebsd-net .. beta version. Check out the blurb on our new improved web site! :-) ftp://ftp.whistle.com/pub/archie/netgraph/index.html -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
Maxim Sobolev writes: Can you point all people (and me of course) who want to test DEVFS to some common information about DEVFS (usage, possible advantages/disadvantages etc. I think some FAQ or so will be nice. It's really will help us to go further with this issue. I agree.. and I've bugged Julian to put something together... Basically, there are a few things that need to be done to get DEVFS into the 'mainstream'... and this includes SLICE. The only thing that DEVFS doesn't completely work for right now is disks, because the way disks are handled right now is all a bunch of hardwired stuff. SLICE is intended to fix this problem, and in the process make easy things like a compressed encrypted filesystem striped across a 10 disk array.. :-) So the things to do are: 1. Finish DEVFS-enabling the SCSI da disk driver. 2. Implement asynchronous device management in DEVFS (kernel thread) This solves the problem of doing lengthy I/O during interrupts. 3. Fix the MFS problem -- hopefully Matt Dillon can help here in the course of his ongoing cleanups bug fixes. 4. Completely rewrite libdisk to use and understand SLICE. (This might actually be a kharmically refreshing experience). 5. Update the installer code to work with the new libdisk OR write a compatibility layer that implements the old libdisk API on top of the new libdisk. 6. No change to fdisk(8); minor change to disklabel(8). I'm willing to take a look at the libdisk issue.. in which case a few helpful pointers from anyone who knows would be nice: - What other code beside the installer (if any) uses libdisk? - What are the relevant installer files in the source tree? -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
- What other code beside the installer (if any) uses libdisk? Nothing does. That probably says something in and of itself. :) - What are the relevant installer files in the source tree? /usr/src/release/sysinstall. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DEVFS, the time has come...
Poul-Henning Kamp writes: ... to make up our mind about it. [ clear arguments for DEVFS and why persistence is complicated ] This email was a few weeks ago, and there was a lively debate, then Julian sent an email listing some issues/requirements, and then the thread kindof died and now we're back to where we were before, which is not any further on.. So I'd like to make another attempt to get agreement on the next step here, so that *something* can happen. We need to get more people using DEVFS, so we can gain some experience feedback. I don't think DEVFS has any issues that are not surmountable. However, at some point you must take the next step. To do this, we need to come up with a 'next step' that doesn't necessarily make everybody happy, but does make enough people happy that they can use it and it becomes somewhat 'mainstream'... Here's my proposal, which is basically the same thing Poul was suggesting: - Have a non-persistent DEVFS in the kernel; when devices appear they have the default permissions - Have an /etc/rc.devices script to make any site-specific customizations at boot up - Have a mount flag that would disable the apperance of new devices - DEVFS remains a kernel option for now To try and answer some of the issues from Julian's email, in the interest of making decisions so we can proceed: 3/ The filesystem needs to give a method to allow new devices to appear as created. If the layout of a /chroot/dev filesystem has been changed, then you need to work out WHERE in the filesystem to create the new device. Devices should appear in the same place (relative to the root of the mount) every time. For now, this path can be hardwired in the device driver. 4/ If a user changes the name of a device or makes a link to it, those devices must still be removed when the device becomes invalid. ... 6/ If a process has a device open and it 'goes away', what should happen? No automatic removal of device nodes.. if the device goes away, then operations start returning ENXIO or whatever. After all, this is what a non-DEVFS system would do in the same situation (if it could). 7/ Persistence is I think a WOFTAM. Some people want it. It could be ignored in my opinion but you should at least have a scheme in mind.. My suggestion is to pick up permissions and owners from inodes of the same name read from the filesystem on which the devfs was mounted. A synthetic / filesystem (An idea that I know Poul has been kicking around for a while) wouldn't be able to do that, but there are other ideas I guess. Devices appear with default permissions and ownership... always. What about a new device that appears when I insert my PCCARD? Well, you can always do what you do now, which is not have them appear, So at least things get no worse. Well, actually now I have the device node with my special permissions set already created in /dev, so when the PCCARD is inserted, the device node already exists with those permissions... Good question.. for now, we ignore this case (and potentially lose a few DEVFS customers). Solving this can be part of the next step. Ideas: (a) have a user daemon; (b) have DEVFS inherit permissions from a 'stub' node of the same name that already exists (if any) when the device appears (then /etc/rc.devices could do its thing for these dynamically appearing nodes as well). 5/ If a device has its modification time changed, does that change reflect through all instances of that device? (E.g. /dev/xxx and /chroot/dev/xxx). What about permissions? What about ownerships? No.. separate nodes are separate files, they just refer to the same device. OK.. so there is some percentage X% of people for whom this proposal would be sufficient to use DEVFS on their systems. Personally, I find it hard to believe that X is not a large number, because for normal usage you'd get exactly what we have now, functionally speaking. It seems like this proposal would make DEVFS acceptable for a large percentage of folks.. but definitely not 100% -- and that's OK for a first step. Ultimately, we want to get to a fully DEVFS world. By taking a few steps at a time, and getting people to *use* it, we can eventually discover and address everybody's concerns. Comments?? The issue here is not whether this proposal is a sufficient *final* incarnation of DEVFS, but whether it's a sufficient next step.. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
