Date: Sat, 14 Feb 1998 16:07:00 +0800 From: Peter Wemm <peter@netplex.com.au> To: Joao Carlos Mendes Luis <jonny@coppe.ufrj.br> Cc: mike@smith.net.au (Mike Smith), julian@whistle.com, phk@critter.freebsd.dk, committers@FreeBSD.ORG Subject: Re: devfs persistance Message-ID: <199802140807.QAA00724@spinner.netplex.com.au> In-Reply-To: Your message of "Sat, 14 Feb 1998 04:04:48 -0200." <199802140604.EAA06373@gaia.coppe.ufrj.br>
next in thread | previous in thread | raw e-mail | index | archive | help
Joao Carlos Mendes Luis wrote: > #define quoting(Mike Smith) [..] > // > If you need any change, just edit the file and cat it again. > // > // No. Definitely not. devperms is for single-device overrides, and its > // contents will respond to chown/chmod operations to avoid violating POLA. > > Sorry, I missed the meaning of POLA. Principle Of Least Astonishment.. ie: aim for what is going to cause the least amount of suprise/astonishment etc. > But in this point I agree with PHK in the sense that I want the > devices in a known condition after booting. When a user logs, > not only his terminal gets owned by him, but /etc/fstab could > be used to add even more rights. If my system crashes or reboots > without him logging out, I would prefer not to keeps his rights. > It's not done today, anyway, so it's not a big problem. That's something I had not thought about in detail. It'd be nice to have a flag in devrules to explicitly disallow persistance across reboots of certain classes of devices. > // > The file could be read to get the current configuration, but a > // > change into the mounted system would not reflect into it. Or maybe > // > the could be another device that would read the current config. > // > Maybe a sysctl is needed for the name_to_major approach, since it > // > needs to be loaded before mounting. > // > // It is likely that major numbers will disappear at some stage in the > // not-too-distant future. > > Gulp ^ 2 ! > > What if I want to call a device by another name ? I want to have the > choice to call /dev/fd0 as /dev/floppy. Why ? Because I want, or maybe > because I have a program without sources that needs such a name and does > not accept symlinks. This could get worst with emulation. What if I get > a commercial Linux program to handle some serial device that asks for > /dev/tty00, and I only have /dev/ttyd0 ? A bad program, surely, but > possible. I like to use /dev/mouse and /dev/ups as symlinks to the > real serial devices. And so on. This isn't quite as bizzare as it seems.. 'ln', 'mv' etc will still work. You can easily 'ln ttyd0 tty00' and it'll "just do it". Creating a device node should never really be needed as all nodes will exist for all present devices. Julian has implemented cross device hard links for devfs trees to get around some of the chicken-or-the-egg problems. If you delete nodes accidently and want them back, you can mount another instance of devfs with all nodes present, and do a cross-device 'ln' to re-create the nodes. Don't forget that we also have a VOP_UNDELETE and so on now, so the existing undelete command could probably be made to undo a deletion. I wonder if a unionfs-like whiteout concept would serve us well here? ie: if a node is deleted, a "whiteout" or "delete" tag could be put in it's place. If the device went away and came back, the delete tag could ensure the node stayed deleted. There could also be a 'rename' and/or 'link' tag, so if you linked /dev/ttyd0 to /dev/tty00, a "link" tag would be created. If you rebooted, disabled your serial hardware and powered up, both ttyd0 and tty00 would be gone (but the link tag would persist). If you reboot again with the serial hardware present again, then ttyd0 and tty00 would automagically reappear. I suspect this would take a fair amount of work to implement though.. :-) You would presumably be able to do the same thing for a minimal /usr/spool/ftp/dev tree as well. Presumably you'd be able to mount an "empty" devfs tree, and hard link all the devices that you explicitly want from /dev to /usr/spool/ftp/dev. I imagine that the backing store file would be specified in a similar way to how ufs quotas files are done.. ie: mount -o userquota=/home/quotas /tmp and so on. It'd make sense to be able to choose backing store and rules files for devfs mounts, and to be able to specify things like population state (ie: initially empty, initially full, or as previously set from backing store files) and so on at mount time. It should also be possible to specify in the rules file things like pty and tty files automatically resetting their permissions back to defaults after last close. An implementation of device cloning would be really simple and robust.. (ie: open /dev/ptymaster, and a /dev/ttypN would automatically appear for you with the userid of opener of the master as the owner and mode 600.. You can't get much more safer or secure than that). These sorts of things are where devfs could really pay off. > Jonny Cheers, -Peter -- Peter Wemm <peter@netplex.com.au> Netplex Consulting To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802140807.QAA00724>