> > Without any planing or forethought. It's procfs all over again.
>
> ???
> pcihpfs is well planned. So are all of the different filesystems
> that are now present. They do one thing, and one thing only. Much
> unlike procfs. That's why driverfs was not implemented within procfs.
All the f
On Thu, Mar 21, 2002 at 12:55:19AM +0100, Oliver Neukum wrote:
> On Thursday 21 March 2002 00:22, Greg KH wrote:
> > On Wed, Mar 20, 2002 at 11:17:25PM +0100, Oliver Neukum wrote:
> > > > What ones? I can't think of any right off the top of my head.
> > >
> > > ioctls for getting complex informat
ioctl has fundamentally different semantics to read/write.
An ioctl does something and returns a result, its synchronous in its
action/reply.
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinf
On Thursday 21 March 2002 00:22, Greg KH wrote:
> On Wed, Mar 20, 2002 at 11:17:25PM +0100, Oliver Neukum wrote:
> > > What ones? I can't think of any right off the top of my head.
> >
> > ioctls for getting complex information.
>
> read() works fine for getting complex information too :)
One ki
On Wed, Mar 20, 2002 at 06:21:54PM -0500, Johannes Erdfelt wrote:
> I don't know if you have to implement it to find out. How about a rough
> design?
Will do.
> > What do you mean, "real virtual driver filesystem"?
>
> Something people will accept. /proc has been abused too much for this
> kind
On Wed, Mar 20, 2002 at 11:17:25PM +0100, Oliver Neukum wrote:
>
> > What ones? I can't think of any right off the top of my head.
>
> ioctls for getting complex information.
read() works fine for getting complex information too :)
> > > Folk would benefit from being able to bind/unbind drive
On Wed, Mar 20, 2002, Greg KH <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 20, 2002 at 05:11:13PM -0500, Johannes Erdfelt wrote:
> >
> > For those things which don't map easily, perhaps we can do some stuff
> > still as ioctl's, resetting endpoints and clearing halts for instance.
>
> Hm, have to tr
On Wed, Mar 20, 2002 at 05:11:13PM -0500, Johannes Erdfelt wrote:
>
> For those things which don't map easily, perhaps we can do some stuff
> still as ioctl's, resetting endpoints and clearing halts for instance.
Hm, have to try to implement it to see if that's really necessary.
> I'm not again
On Wed, Mar 20, 2002, Maksim Krasnyanskiy <[EMAIL PROTECTED]> wrote:
>
> > > I meant any part of USB core. Whoever calls disconnect
> > > could potentially tell HCD to cancel all requests on this device.
> >
> >The "potential" is that substantial (b) rework.
> Ok. I'll give it more thinking and m
> > I meant any part of USB core. Whoever calls disconnect
> > could potentially tell HCD to cancel all requests on this device.
>
>The "potential" is that substantial (b) rework.
Ok. I'll give it more thinking and may be propose something later. Gotta
study USB code a bit more :).
Just to give
> What ones? I can't think of any right off the top of my head.
ioctls for getting complex information.
> > Folk would benefit from being able to bind/unbind drivers from
> > interfaces (viz that recent VMWare note, and there are other cases
> > too).
>
> Agreed. The pencam userspace program
On Wed, Mar 20, 2002, Greg KH <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 20, 2002 at 12:55:34PM -0800, David Brownell wrote:
> > > > > Ah, I didn't know that. Unfortunately, not all USB drivers have an
> > > > > /proc/ interface like CPiA.
> > > >
> > > > Ok, sorry for jumping in late here, but no i
On Wed, Mar 20, 2002 at 12:55:34PM -0800, David Brownell wrote:
> > > > Ah, I didn't know that. Unfortunately, not all USB drivers have an
> > > > /proc/ interface like CPiA.
> > >
> > > Ok, sorry for jumping in late here, but no ioctl(). I hate the current
> > > usbfs ioctl interface and do not
> > > Ah, I didn't know that. Unfortunately, not all USB drivers have an
> > > /proc/ interface like CPiA.
> >
> > Ok, sorry for jumping in late here, but no ioctl(). I hate the current
> > usbfs ioctl interface and do not want to see that spread at all. usbfs
> > could (and will) change to be r
> > > usb_submit_urb should really have well defined semantics for failures:
> > >
> > > 1. the completion handler is _not called_ and the result of
> > > usb_submit_urb indicates _failure_ (the way uhci handles it now),
> > > ...
> > > 3. the completion handler is _called_ and the result of usb_s
On Tue, 19 Mar 2002, Nemosoft Unv. wrote:
>> > As to the /devfs name... Could be done, but I would like to put the
>> > amount of logic that is needed ina user program to a minimum, so 'old'
>> > style /dev should be listed as well.
>>
>> Major/minor is all that is really needed. If you're usin
On Wed, Mar 20, 2002 at 03:53:47PM +0100, Olaf Hering wrote:
> That patch does indeed fix the problem with some devices, sometimes you
> even need a sleep 5.
>
> But since all that runs in background the bootscripts will continue to
> run. And if gpm wants the /dev/input/mice node and the mousedr
On Mon, Mar 11, Greg KH wrote:
> Hi,
>
> Since the latest USB patch went in that added a proper delay to the
> hub connection sequence, a lot of people have been reporting odd
> problems with some USB hubs, keyboards, and mice. I've seen this
> problem too. It is usually fixed by just repluggi
18 matches
Mail list logo
