From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lucio De Re To: 9fans@cse.psu.edu Subject: Re: [9fans] USB developments Message-ID: <20040115172027.J25947@cackle.proxima.alt.za> References: <20040115164415.I25947@cackle.proxima.alt.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: ; from Fco.J.Ballesteros on Thu, Jan 15, 2004 at 03:56:36PM +0100 Date: Thu, 15 Jan 2004 17:20:27 +0200 Topicbox-Message-UUID: b9fc1af0-eacc-11e9-9e20-41e7f4b1d025 On Thu, Jan 15, 2004 at 03:56:36PM +0100, Fco.J.Ballesteros wrote: > > With enough effort put on that, I'd probably agree with you. However, > I think that would require a lot of effort to learn how to split them clearly > (consider that you'd want your kernel to be operational despite user programs > problems). > OK, I'm really only interested in viability. As long as we agree that it is possible, I assume no one will implement USB management that will preclude moving in the direction I advocate. Difficult does not frighten me, short-sighted implementations do. > Given that, I'd vote for duplication of code. With some effort, the code > can be borrowed "as is", without keeping a different version. I think it will need changing, but that the changes can be back ported to the kernel. As I mentioned, I think the separation between userland and kernel drivers is quite blurred by them appearing as filesystems in both cases. There are underlying issues, but I think the similarity is more significant. My present plan is to strip #U to bare essentials, removing any knowledge it may have of specific USB features and instead allowing it to report changes to the configuration as they occur. I'll use usbd as the foundation for a daemon that does no more than monitor these #U reports and allows me to add configuration and initialisation as I grasp the details better. ++L