Date: Sat, 09 Nov 2002 14:20:41 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Takanori Watanabe <takawata@axe-inc.co.jp> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, current@freebsd.org Subject: Re: getting rid of devfs... Message-ID: <3DCD8A39.9E667036@mindspring.com> References: <200211092126.GAA10577@axe-inc.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
Takanori Watanabe wrote: > In message <64608.1036834305@critter.freebsd.dk>, 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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DCD8A39.9E667036>