[[!meta copyright="Copyright © 2009, 2012 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] `devfs` is a translator sitting on `/dev` and providing what is to be provided in there in a dynamic fashion -- as compared to static passive translator settings as they're used now. `devfs` has not yet been written. [[!tag open_issue_hurd]] --- If applicable, it has to be taken care that all code concerning the page-in path is resident at all times. --- # IRC, freenode, #hurd, 2012-01-29 [[!tag open_issue_documentation]] what would be an hurdish way to achieve something like the various system (udev, devfs, devd, etc) for populating devices files automatically according to the found system devices? (not that i plan anything about that, just curious) it's not really a stupid question at all :) I guess translators in /dev such as a blockfs on /dev/block pinotree: in an ideal world (userspace drivers and all), the device nodes will be exported by the drivers themselfs; and the drivers will be launched by the bus respective bus driver an interesting aspect is what to do if we want a traditional flat /dev directory with unique device names... probably need some unionfs-like translator that collects the individual driver nodes in an intelligent manner # IRC, freenode, #hurd, 2012-04-22 braunr: I don't think it's a problem that translators are invoked when listing /dev the problem is that they linger around although they are very unlikely to be needed again any time soon for now it's not too much a problem because there aren't too many but that can become problematic a devfs on /dev could also fill it with new devices but only with the ones that actually exist yeah antrik: i mean, the hurd may lack a feature allowing the same translator to be used for several nodes not hierarically related antrik: or rather, it's a special case that we should implement differently (with e.g. a devfs that can route requests for different nodes to a same translator ) I agree BTW that some intermediary for /dev would be helpful -- but I don't think it should actually take over any RPC handling; rather, only redirect the requests as appropriate (with the actual device nodes in a hierarchical bus-centric layout) right braunr: actually, the Hurd *does* have a feature allowing the same translator to be attached to several unrelated nodes i keep getting surprised :) though it's only used in very few places right now pfinet and ptys at least ? yeah, and console client IIRC