From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Tue, 8 Jan 2013 10:59:44 +0100 From: cinap_lenrek@gmx.de To: 9fans@9fans.net In-Reply-To: <6013d18eeba127f0c77bf3e6b8ad8255@hamnavoe.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] these are release of 9front? Topicbox-Message-UUID: 02f23162-ead8-11e9-9d60-3106f5b1d025 how can it not interoperate with plan9 programs? the usb subsystem in 9front just organizes the instantiation of userspace drivers differently. the kernel hci drivers and interfaces are the same (biggest difference is that we added buffer delay control for iso endpoints for usb audio). instead of embedding all usb drivers in usbd, we run them as separate fileservers/programs using lib9p instead of a usb-fileserver-driver-framework-factory. to get these fileservers into a global namespace, we created a device that lets one register global mount points. so when i plug in my usb camera, nusb/ptp gets started and the cameras filesystem appears under /shr/sdU1.2 ect. a lot of complexity can be removed from the drivers when one has its own processes and not have to worry about sharing memory and filedescriptors with everything else. a crash in one driver doesnt bring all usb down and one can just kill a driver and attach another one for debugging without loosing the other devices or the hub. in a way, this is just like the old usb stack worked. you just have a small usb helper lib for common stuff like activating endpoints and parsing descriptors and distinct programs for drivers. to make it work for hotplug, you use the /shr instead of /srv. all this doesnt matter for programs using usb devices. the filesystem interfaces behave the same. -- cinap