Date: Thu, 12 Nov 1998 14:59:29 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: zhihuizhang <bf20761@binghamton.edu> Cc: hackers <freebsd-hackers@FreeBSD.ORG> Subject: Re: More questions on DEVFS Message-ID: <Pine.BSF.3.95.981112144551.17800F-100000@current1.whistle.com> In-Reply-To: <Pine.SOL.L3.93.981112115703.7465B-100000@bingsun1>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 12 Nov 1998, zhihuizhang wrote: > > I have a couple of questions on DEVFS which is hard to figure out from the > source code: > > (1) As I understand it, special files can be created only by superuser via > mknod and file systems can only be mounted by superuser. I do not see any > reason why the superuser will mount the device file system multiple times > and possibly at different mount points. Eventually if devfs were common the ability to have devices on other filesystems would be removed. Requiring the administrator to keep in sync with dynamically assigned device major.minor numbers is impossible. (wellll... hard) In that case no-one (not even root) could make device nodes because they wouldn;t know what major number to use.. only the kernel knows that. Having multiple copies of /dev is common in chroot environments. > > (2) Both the block and character switch table have a major number at its > end (d_maj) which is often set to be -1 (see mem_cdevsw[] in file > i386/mem.c for an example). This makes devfs_add_devswf() return without > adding a device entry. Is this the way that is used to circuit the DEVFS > code on purpose? in -current there is no longer a bdevsw ond a cdevsw struct. there is only a single 'devsw' struct.. d_maj is so the driver can see what major it was assigned in th ecase where it may have been dynamically assigned.. It was also so that you could find hte mojor of the char device coresponding with a block device as there was a pointer from the blksw enty to the associated cdevsw entry, and using that you could look at d_maj to find the major of the other device. Now in -current there is on ly one struct that is pointed to by both arrays so there is a d_maj and a d_bmaj.. Eventually the whole bdevsw array will go away. block devices are not terribly useful any more. devfs_add_devsw assumes that the devsw entry has first been put into the devsw array, (pointed to rather). the routines that do this (in kern_conf.c) replace the -1 with the real number. Each driver has an init routine that is called either by the SYSINIT() entry at EARLY boot time, or when it is loaded (if it is an lkm/klm/mlk/etc.) It is the responsibility of this init routine to place the devsw entry into the table. THis usually happens well before the prob/attach routines which add the devfs entries for those specific devices they find. devsw entries are PER DRIVER devfs entries are PER FOUND DEVICE. They have different scopes. julian > > Thanks for your help. > > -------------------------------------------------- > | Zhihui Zhang, http://cs.binghamton.edu/~zzhang | > | Dept. of Computer Science, SUNY at Binghamton | > -------------------------------------------------- > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.981112144551.17800F-100000>