[[!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]] <pinotree> 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? <pinotree> (not that i plan anything about that, just curious) <youpi> it's not really a stupid question at all :) <youpi> I guess translators in /dev <youpi> such as a blockfs on /dev/block <antrik> 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 <antrik> 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 <antrik> braunr: I don't think it's a problem that translators are invoked when listing /dev <antrik> the problem is that they linger around although they are very unlikely to be needed again any time soon <youpi> for now it's not too much a problem because there aren't too many <youpi> but that can become problematic <pinotree> a devfs on /dev could also fill it with new devices <youpi> but only with the ones that actually exist <pinotree> yeah <braunr> antrik: i mean, the hurd may lack a feature allowing the same translator to be used for several nodes not hierarically related <braunr> antrik: or rather, it's a special case that we should implement differently <braunr> (with e.g. a devfs that can route requests for different nodes to a same translator <braunr> ) <antrik> 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) <braunr> right <antrik> braunr: actually, the Hurd *does* have a feature allowing the same translator to be attached to several unrelated nodes <braunr> i keep getting surprised :) <antrik> though it's only used in very few places right now <youpi> pfinet and ptys at least ? <antrik> yeah, and console client IIRC