The proc_ioctl() function in devio.c which invokes the driver specific
ioctl appears to take care of copying the data structure back to user
space (on or about line 1087 of devio.c).
Allen
Mark McClelland wrote:
>
> Allen Barnett wrote:
>
> > + case USBDEVFS_DRIVER_DEVINFO:
> > +
Allen Barnett wrote:
> + case USBDEVFS_DRIVER_DEVINFO:
> + devinfo = (struct usbdevfs_driver_devinfo *)buf;
> + devinfo->type = S_IFCHR;
> + devinfo->major = USB_MAJOR;
> + devinfo->minor = ((struct usblp
>*)(dev->actconfig->interface
Here is a patch which implements the outline below. A new structure
is added to usbdevice_fs.h and a new ioctl function is added to be passed
along to the device driver. An implementation of the ioctl for the
USB printer.c module is also here. There are not many changes because
the infrastructure
On Wednesday 04 April 2001 02:12, you wrote:
> Thats the bit devfs solves. Its the enumeration problem. You need to answer
> questions like 'what modems have I got right now' 'where is my sound' and
> 'is there a mouse'. For USB thats very important.
Yes, that's why I am working on the device reg
> What I dont understand is: why is the name of a device file more important
> than, for example, its major/minor number or the name of a /proc file? It is
It isnt
> future no user will specify it anymore unless you have a REALLY complicated
> scheme to preserve device names over reboots and
On Wednesday 04 April 2001 01:37, you wrote:
> Obvious, neat, and of course like all obvious neat ideas - broken - because
> devfs is dynamic so the symlink maintenance is dynamic. That means you need
> to either solve enough races to put devfs in userspace or internationalise
> devfs in the kerne
> > devfs is a solution to enumeration of devices, not the general problem. Its
> > also currently severely limited as it places language policy in kernel
>
> I agree with everyone else. This is a good thing. If people really want
> a different language, then use symlinks.
Obvious, neat, and of
>Is devfs ever likely to be the default mode of
> operation, to warrant developing solutions based on it?
Sounds like a fine topic for a flamewar ... :)
And there's "devfsd" to consider separately.
- Dave
___
[EMAIL PROTECTED]
To unsubscribe
>> = David Brownell
> = Greg KH
> > dev_tdev;/* major/minor */
>
> Eeek! No, don't do that! That will be going away in 2.5 :)
It's April 3, not April 1 ... ;)
I heard the idea was "typedef u32 dev_t;" and then to have
fun making that namespace couple sanely to /dev/filena
On Tue, Apr 03, 2001, Alan Cox <[EMAIL PROTECTED]> wrote:
> > It looks (from http://lwn.net/2001/features/KernelSummit/annotated.jpg)
> > like Greg KH and JE were the USB influence at the 2.5 summit. So I
> > assume that some "USB in 2.5" was discussed - at least off line.
> > So where is Linux U
On Tue, Apr 03, 2001, Alan Cox <[EMAIL PROTECTED]> wrote:
> > >From what little I understand of devfs, this seems to be the most
> > reasonable solution. Is devfs ever likely to be the default mode of
> > operation, to warrant developing solutions based on it?
>
> devfs is a solution to enumerati
> >From what little I understand of devfs, this seems to be the most
> reasonable solution. Is devfs ever likely to be the default mode of
> operation, to warrant developing solutions based on it?
devfs is a solution to enumeration of devices, not the general problem. Its
also currently severely
Greg KH wrote:
>
> On Sat, Mar 31, 2001 at 07:25:48AM -0800, David Brownell wrote:
> > dev_tdev;/* major/minor */
>
> Eeek! No, don't do that! That will be going away in 2.5 :)
I tried it anyway (except I have 2 int's instead of a dev_t :-) Does
anyone care?
> I've been t
> It looks (from http://lwn.net/2001/features/KernelSummit/annotated.jpg)
> like Greg KH and JE were the USB influence at the 2.5 summit. So I
> assume that some "USB in 2.5" was discussed - at least off line.
> So where is Linux USB going guys?
My tree is keeping dev_t and the standard behaviou
Greg KH wrote:
>
> On Sat, Mar 31, 2001 at 07:25:48AM -0800, David Brownell wrote:
> > dev_tdev;/* major/minor */
>
> Eeek! No, don't do that! That will be going away in 2.5 :)
Ah, just the entry I was looking for :)
It looks (from http://lwn.net/2001/features/KernelSummit/
On Sat, Mar 31, 2001 at 07:25:48AM -0800, David Brownell wrote:
> dev_tdev;/* major/minor */
Eeek! No, don't do that! That will be going away in 2.5 :)
I've been thinking about this for a while, and I don't think that we
need to export anything else to userspace right now.
> This seemed pretty straight-forward so I thought I'd take a shot at
> implementing this as my first attempt at kernel hacking.
We all had to start somewhere ... :)
> However, I've
> run into a problem in the user space end of it. In
> /usr/include/asm/types.h, dev_t is defined as 'short'.
This seemed pretty straight-forward so I thought I'd take a shot at
implementing this as my first attempt at kernel hacking. However, I've
run into a problem in the user space end of it. In
/usr/include/asm/types.h, dev_t is defined as 'short'. In
/usr/include/bits/types.h dev_t is defined as a '_
Adam J. Richter wrote:
> Finally, on a note that actually has something to do with USB,
> I just want to make clear that you can currently read the IEEE-1284
> parallel port device ID information with a stock 2.4.3 kernel, under
> any of the following scenarios, which cover just about everyt
>> = ???
> = David Brownell
>> Would it be possible (or reasonable) to add an ioctl to usbdevfs which
>> can ask for this information via the /proc/bus/usb/###/### interface? Or
>> should the printer.o module execute a user-space helper app to do this
>> configuration itself?
>IMHO, either of t
Hmm. This work that you are doing sounds like it might
have value beyond the USB domain. Perhaps you should
be CCing [EMAIL PROTECTED]?
It's important that everyone doing hotplug related work
keep linux-hotplug-devel in the loop.
Cheers,
Miles
Tim Jansen wrote:
>
> On Fri, Mar 30, 20
> From: "Tim Jansen" <[EMAIL PROTECTED]>
> Sent: Saturday, March 31, 2001 12:40 AM
>
> I'm working on the device registry patch (www.tjansen.de/devreg) that allows
> you to retrieve the DevFS filename of a physical device. The next release
> will be in a couple of days and adds a DEVICEID environ
> Would it be possible (or reasonable) to add an ioctl to usbdevfs which
> can ask for this information via the /proc/bus/usb/###/### interface? Or
> should the printer.o module execute a user-space helper app to do this
> configuration itself?
IMHO, either of those would be reasonable 2.4 soluti
On Fri, Mar 30, 2001 at 03:26:54PM -0500, Allen Barnett wrote:
> after printer.o is loaded, however, there doesn't seem to be enough
> information passed in from the hotplug invocation to extract the minor
> device number of the newly plugged in device. (The user-space daemons
> want to access /de
I see that this was discussed some back in September but I couldn't find
a resolution.
David Paschal has written user-space drivers for HP OfficeJets. When you
connect the OJ via USB, the current hotplug scripts will load the
printer.o module, but, it would also be helpful if it would start the
u
25 matches
Mail list logo
