devfs
[Top] [All Lists]

Re: devfs and USB

To: devfs@xxxxxxxxxxx
Subject: Re: devfs and USB
From: Johannes Erdfelt <jerdfelt@xxxxxxxxxxx>
Date: Tue, 18 Apr 2000 09:07:59 -0700
In-reply-to: <200004180627.e3I6RVr29809@xxxxxxxxxxxxxxxxxxxxxxxx>
References: <20000417194508.G14581@xxxxxxxxxxx> <200004180255.e3I2toJ27552@xxxxxxxxxxxxxxxxxxxxxxxx> <20000417200237.I14581@xxxxxxxxxxx> <200004180338.e3I3cng27991@xxxxxxxxxxxxxxxxxxxxxxxx> <20000417205739.A12513@xxxxxxxxxxx> <200004180414.e3I4EOO28467@xxxxxxxxxxxxxxxxxxxxxxxx> <20000417220458.B12513@xxxxxxxxxxx> <200004180601.e3I612v29463@xxxxxxxxxxxxxxxxxxxxxxxx> <20000417231455.D12513@xxxxxxxxxxx> <200004180627.e3I6RVr29809@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: owner-devfs@xxxxxxxxxxx
On Tue, Apr 18, 2000, Richard Gooch <rgooch@xxxxxxxxxxxxxxx> wrote:
> Johannes Erdfelt writes:
> > Yup. We use private_data to point to a struct usb_device * or a
> > struct usb_endpoint_descriptor * for instance.
> 
> Really? I just did a scan of drivers/usb/ in 2.3.99-pre6-2 and I don't
> see you passing pointers to <devfs_register>. In input.c all I see is
> a conventional driver with basic devfs support added.

Patches haven't been merged yet. Take a look at the patch I sent you.

And those should be using pointers, but I haven't looked at how they are
implemented.

> > We have a separate set of file_operations for the different types of
> > nodes we want.
> 
> I only see &input_fops being passed (there's only one call to
> <devfs_register> anyway:-).

See above.

> > I'd suppose that keeping them separate would probably the best for
> > now.  Things will be changing rapidly and I don't want to burden the
> > rest of devfs or devfsd with USB development for now.
> 
> Yeah, makes sense to me. Is there anything you need changed in devfsd?
> I'm hoping that the recent changes provide you all the hooks you need.

That's most of it. The only other changes I need are things like exporting
variables so SYSLOG will work, etc.

> > That was the intention. The necessary support wasn't there that we
> > needed, so we created it. devfs provides a super set of
> > functionality that we need so making the change is not much of a
> > problem.
> > 
> > I was busy tracking down and fixing some other bugs today so I
> > didn't get much time to actually work on the coding for moving the
> > rest of the core to devfs, but work will continue.
> 
> In the last email I had with Thomas Sailer, he didn't seem to think
> there was much advantage to using devfs, and he felt that there were
> special-purpose things needed for USB that wouldn't belong in devfs.

I've talked to him and he hasn't told me why it's not possible to use
devfs. He mentioned locking issues and race conditions once, but he hasn't
expanded on it in multiple emails sent to him.

So, if we can use devfs and remove all of the VFS specific code, we have
a net win.

Less code to maintain on our end.

> BTW: do you prefer to be Cc'ed or not? I have duplicate filtering, so
> a second copy doesn't bother me;-)

I don't have duplicate filterings, but I can delete by hand, doesn't bother
me much. I'm used to it on the rest of the lists I'm on.

JE


<Prev in Thread] Current Thread [Next in Thread>