Messages in this thread | | | From | "Chris Smith" <> | Subject | Re: UUIDs (and devfs and major/minor numbers) | Date | Tue, 15 Jun 1999 13:44:15 -0600 |
| |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content="text/html; charset=iso-8859-1" http-equiv=Content-Type> <META content="MSHTML 5.00.2314.1000" name=GENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=#ffffff> <DIV><FONT face=Arial size=2>Hi,</FONT></DIV> <DIV> </DIV> <DIV><FONT face=Arial size=2>This isn't a direct reply to anyone; just getting a thought out there. It seems like most of the objection to devfs has been to its use of bus locations rather than logical identifications of a disk in locating them. But is it really any more difficult to build a logical volume view of the disks in a system on top of devfs than it is to do the same on top of a physical dev filesystem? Actually, I would think it's easier, since programs like LILO just have to check devices that are actually present for that UUID.</FONT></DIV> <DIV> </DIV> <DIV><FONT face=Arial size=2>I think the ultimate hypocrisy (sp?) in this discussion is that a lot of people are saying that policy should be kept out of the kernel, but then criticizing devfs for not handling policy. UUID's, volume labels, and so forth are definitely policy. They can be handled in user space, and in some cases, despite a static dev filesystem being a poor abstraction to build on top of, applications do handle them at user-level. Names in the dev filesystem are NOT policy. They have just been used that way because any appropriate policy does not exist.</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>So how about we stop criticizing devfs for what it doesn't do, and instead start thinking about how it improves what we have right now.</FONT></DIV> <DIV> </DIV> <DIV><FONT face=Arial size=2>Chris Smith</FONT></DIV> <DIV><FONT face=Arial size=2></FONT> </DIV> <DIV><FONT face=Arial size=2>PS. Maybe I missed this in the Union FS discussion, but has anyone thought about the implications of unionfs in solving some of the remaining hacks in devfs? Take, for example, required sockets for init. Just a thought for the future. (Although from a purist perspective, which I admit to occasionally holding, I'd say we probably ought to start changing init programs to not use sockets in /dev -- that seems like a poor place for such a socket)</FONT></DIV> <DIV> </DIV></BODY></HTML>
| |