Date: Fri, 8 Nov 2002 20:31:23 -0800 (PST) From: julian@FreeBSD.ORG (Julian Elischer) To: kris@obsecurity.org Cc: current@FreeBSD.ORG Subject: Re: getting rid of devfs... Message-ID: <20021109043123.0555F37B401@hub.freebsd.org> In-Reply-To: <20021109035817.GA29018@rot13.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 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?20021109043123.0555F37B401>