Re: getting rid of devfs...
Poul-Henning Kamp [EMAIL PROTECTED] writes: [2] I simply cannot see us kldload'ing stuff in response to ls -l /dev/watchthis In fact, I think a lot of people would get very angry if we did this, as it might turn ls(1) into panic(1). DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: getting rid of devfs...
In message [EMAIL PROTECTED], Julian Elischer writes : In fact majors and minors, being dynamic, could change from boot to boot. And just to calm down anybody who's getting nervous now, this is not happening quite yet :-) After the next branch of -current, be it before/after 5.0-R or 5.1-R, and provided nothing terminal pops up in the meantime: I will commit the following changes: DEVFS: 1. DEVFS will become standard (ie: no disabling option). 2. Remove cdevsw_add() and cdevsw_remove() and makedev(). 3. major/minors will be dynamically assigned. GEOM: 1. GEOM will become standard (ie: no disabling options). 2. Legacy code will be removed. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: getting rid of devfs...
Julian Elischer wrote: Ok here are some thought about devfs 1/ devices are coming and going and becoming more portable 2/ disk partitioning schemes are also multiplying 3/ devices such as usb or bluetooth nets can be configured in arbitray ways 4/ there are more than 256 types of device in the world. With these in mind, devfs takes a device NAME and directly maps it to teh driver in a way that is not controlled by the minor number. [ ... lots of other stuff that's obvious, if you paide attention when Julian's first devfs implementation was submitted for inclusion in FreeBSD ... ] So... When are you going to delete specfs? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
getting rid of mknod? (was Re: getting rid of devfs...)
You can still make device nodes so that the disk can be exported, but as, in -current the major and minor number will not exist ...Or use softlinks, perhaps? I can't seem to read mknod(8) disk device nodes anymore in -current. Andrew Lankford To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: getting rid of devfs...
In message [EMAIL PROTECTED], Poul-Henning Kamp wrote: DEVFS: 3. major/minors will be dynamically assigned. So we will need file to list node id list in printf(9) format, instead of /sys/conf/majors. And more better if we generate device name #define or array of string from the file. This will help us implementing loading module when an user process attempt to open some nodes that owned by unloaded modules. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: getting rid of devfs...
In message [EMAIL PROTECTED], Takanori Watanabe writes: In message [EMAIL PROTECTED], Poul-Henning Kamp wrote: DEVFS: 3. major/minors will be dynamically assigned. So we will need file to list node id list in printf(9) format, instead of /sys/conf/majors. I am not sure about this... [1] And more better if we generate device name #define or array of string from the file. This will help us implementing loading module when an user process attempt to open some nodes that owned by unloaded modules. and even less about this... [2] That said, just because I don't like it doesn't mean that people should try to prototype it and see if I'm wrong... Poul-Henning [1] A major part of the drive behind DEVFS is to avoiding the need to register device drivers in a magic, global file. I will agree that it is an predictable outcome that one day two drivers will both try to be /dev/foo but he, they get to haggle that one out for themselves. [2] I simply cannot see us kldload'ing stuff in response to ls -l /dev/watchthis (This is a trick answer: The point is that at VOP_LOOKUP time where the device cloning runs, you don't know for what operation the VOP_LOOKUP is called: stat, open, remove, rename... (Well, some of them you do, but not the interesting ones). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: getting rid of devfs...
Takanori Watanabe wrote: In message [EMAIL PROTECTED], Poul-Henning Kamp wrote: DEVFS: 3. major/minors will be dynamically assigned. So we will need file to list node id list in printf(9) format, instead of /sys/conf/majors. No. The wired relationship must go away, per the comments in /sys/conf/majors: | Hopefully, this list will one day be obsoleted by DEVFS, but for now | this is the current allocation of device major numbers. And more better if we generate device name #define or array of string from the file. This will help us implementing loading module when an user process attempt to open some nodes that owned by unloaded modules. No. The way to deal with this is a seperate section in the module, which is loaded unconditionally, and provides information about the debvice, such as it's name, type (cloning, etc.), ownership, and permissions. Then the device would exost in devfs without the code to implement it. An attempt to access the device would load the other sections of the module, and wire them into the stub section automatically (demand-loading). Doing this by name would be a very, very bad thing, since it would require a mapping between device name and implementation, which is what devfs is trying to avoid; major/minor is just a namespace, after all: if you were to do this by name, you might as well create the device nodes, and use the major/minor as the mapping. One of the problems that devfs is trying to solve is to get rid of static naming, to get rid of centralized management of a namespace (Changing Can I have a major number? to Can I have a device name? is just trading one problem for another). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
getting rid of devfs...
how are you supposed to get rid of devfs? building a kernel without it won't boot since there are no devices... shouldn't there be a ./MAKEDEV all or something underneath the devfs mount so you can boot without it? or am i missing something? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: getting rid of devfs...
In message [EMAIL PROTECTED], Anti writes: how are you supposed to get rid of devfs? You're not. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: getting rid of devfs...
and if you must? dual boot 4.7 here so was able to create the devices easy enough from there and all is well, but i'd like to do it on some other boxes where this isn't an option... On Sat, 09 Nov 2002 00:14:08 +0100 Poul-Henning Kamp [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Anti writes: how are you supposed to get rid of devfs? You're not. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: getting rid of devfs...
On Fri, Nov 08, 2002 at 06:14:09PM -0600, Anti wrote: and if you must? dual boot 4.7 here so was able to create the devices easy enough from there and all is well, but i'd like to do it on some other boxes where this isn't an option... Perhaps you could explain why it's not an option. Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: getting rid of devfs...
Ok here are some thought about devfs 1/ devices are coming and going and becoming more portable 2/ disk partitioning schemes are also multiplying 3/ devices such as usb or bluetooth nets can be configured in arbitray ways 4/ there are more than 256 types of device in the world. With these in mind, devfs takes a device NAME and directly maps it to teh driver in a way that is not controlled by the minor number. In the old scheme you had to have some algorythm to map a minor number to a partition or a virtual device or a logical instance. In the case of ttys this wasn't too hard, but even that grew to take several minor numbers per device, and disk partitions became impossible to correctly describe in the bits allocated.. Thus the GEOM code for example divides up the disk and exports a number of device names to /dev, but depending on the way the drive is layed out there may be no possible wy to describe that layout using the old bitmask scheme. for example in GEOM you can theoretically partition ad0s3d into another set of partitions so you would have ad0s3da, ad0s3db ad0s3dc ad0s3dd etc. You CAN NOT describe that as the old bitmask set. other possibilities include striping two disks together under GEOM.. how do you describe that? When we pass the 255th device driver what major number do you assign to the next one? You can still make device nodes so that the disk can be exported, but as, in -current the major and minor number will not exist (in effect it would be like they are being defined dynamically..i And -current will eventually ignore such nodes. they are for export only in case you need to export a filesystem to (say) linux. In fact majors and minors, being dynamic, could change from boot to boot. You would have no way to know what major and minor numbers to put on the nodes.. major and minor numbers are not needed and are going away entirely. the act of accessing the name in /dev is enough to identify to the kernel which driver to talk to and to identify to the driver which instance you are interested in. If you load a kernel module that wants major number x and soemone else writes a module that wants major number x, in teh old scheme you had to define a scheme to resolve the problem.. with devfs there IS no problem. For this all to work though we have to get rid of major numbers and minor numbers as such, and so once you've crossed that bridge there is no going back. Once devfs is standard, it's manditory (in effect.) julian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
