[uml-devel] [ link to patch] resurrecting the uml-hcd

[uml-devel] [ link to patch] resurrecting the uml-hcd

[James McMechan]

I am attempting to resurrect the uml-hcd driver
this version is based off of the gadget/dummy_hcd.c driver.

I am aiming at a 2.6.12.2 target where it will be used.
I have forward ported it to 2.6.17.6 for testing and hopefully
eventual inclusion.

This patch has a #PLATFORM to deal with the issues between
2.6.17.6/2.6.12.2 since platform_register... is not present in older
kernels and the new kernels don't work with the older registration.

For some reason the usb core is not sending hub urbs to my hcd
all the control seems to run through hub_control and hub_status_data
both of which are not checked before calling and so segfaults the kernel
if not present rather than queuing a control urb to get the
status as I would have expected...

Now I realize, that in hub_control I can assemble a urb out of the data
presented and call my enqueue method, but it looks like that would
be unusually dense of me, since it appears that there should already be
some way to get the urbs.

Notes:
I found that core/message.c does not include asm/scatterlist.h
it appears to assume that linux/pci.h has the scatterlist stuff,
but since UML has no PCI at all pci.h does not include it.
I just added the scatterlist.h should I have removed pci.h?

On 2.6.17.6 it segfaults in the core at hub.c:2251 dev_dbg
where udev->bus->controller->driver->name is used without checking
if driver == NULL which it was in my version.  I have not figured out
where that driver is supposed to be set since the controller appears to
be created in the usb core somewhere...
This patch now checks for that.

Does anyone know where bus->controller->driver is supposed to be set?

uml-hcd is currently partly operational
I can enumerate the device, libusb will talk to it.
Control URBs seem to go back and forth.
and report status back correctly.

I have walked through the usbmon output on the host and the hub simulation
is producing the same status in the same order as the host does
the host appears to produce urbs for its root hub however.
under uml usbmon does not show up in /sys/kernel/debug so
I have not been able to test it there, my current spew level dev_info dumps
all the hub control/status to my console.

Your thoughts are welcome, I would hate to have to fall back to creating a
virtual proc files system that just forwards all the libusb calls down to 
the
host OS.  This was working a few years ago and it looks (from dummy_hcd.c
and usbip) that it should be possible here. I know it was possible to write
a complete usb from userspace without requiring a stub driver back in
the bad old days of 2.4.18...

No doubt this version takes may liberties with the core and driver model
if you could point out some of the more obvious ones to me,
I still was thinking about the automatic interrupt urb submission when last
this was current.

The patch can be fetched from 
http://mysite.verizon.net/james.mcmechan/uml-hcd.2.6.17.6.patch
or bzipped as 
http://mysite.verizon.net/james.mcmechan/uml-hcd.2.6.17.6.patch.bz2
it is 1104 lines long & 31K in size so I stuck it on a web page.

Enjoy,

James McMechan



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [ link to patch] resurrecting the uml-hcd

[Blaisorblade]

On Sunday 13 August 2006 06:10, James McMechan wrote:
> I am attempting to resurrect the uml-hcd driver
> this version is based off of the gadget/dummy_hcd.c driver.
>
> I am aiming at a 2.6.12.2 target where it will be used.
> I have forward ported it to 2.6.17.6 for testing and hopefully
> eventual inclusion.
>
> This patch has a #PLATFORM to deal with the issues between
> 2.6.17.6/2.6.12.2 since platform_register... is not present in older
> kernels and the new kernels don't work with the older registration.

That's ok in drivers, however if at all possible have that in headers rather 
than code (i.e. as CodingStyle says, it's better:
#ifdef a
#define func() func_old()
#else
#define func() func_new()
#endif
...
func()

rather than:

#ifdef a
	func_old();
#else
	func_new();
#endif

> For some reason the usb core is not sending hub urbs to my hcd
> all the control seems to run through hub_control and hub_status_data
> both of which are not checked before calling and so segfaults the kernel
> if not present rather than queuing a control urb to get the
> status as I would have expected...
>
> Now I realize, that in hub_control I can assemble a urb out of the data
> presented and call my enqueue method, but it looks like that would
> be unusually dense of me, since it appears that there should already be
> some way to get the urbs.
>
> Notes:
> I found that core/message.c does not include asm/scatterlist.h
> it appears to assume that linux/pci.h has the scatterlist stuff,
> but since UML has no PCI at all pci.h does not include it.
> I just added the scatterlist.h

> should I have removed pci.h? 
Not at all.

> On 2.6.17.6 it segfaults in the core at hub.c:2251 dev_dbg
> where udev->bus->controller->driver->name is used without checking
> if driver == NULL which it was in my version.  I have not figured out
> where that driver is supposed to be set since the controller appears to
> be created in the usb core somewhere...
> This patch now checks for that.

> Does anyone know where bus->controller->driver is supposed to be set?

I'm seeing in your base driver this code:

static struct platform_driver dummy_hcd_driver = {
        .probe          = dummy_hcd_probe,
        .remove         = dummy_hcd_remove,
        .suspend        = dummy_hcd_suspend,
        .resume         = dummy_hcd_resume,
        .driver         = {
                .name   = (char *) driver_name,
                .owner  = THIS_MODULE,
        },
};
.driver is a device_driver, and I suppose that udev->bus->controller->driver 
should point to it (if you are building a driver for the controller, i.e. the 
HCD driver).

I can provide a pointer to:
http://lwn.net/Kernel/

and some links you can find from it:

http://lwn.net/Articles/driver-porting/
http://lwn.net/Articles/2.6-kernel-api/
http://lwn.net/Kernel/LDD3/ (the complete Linux Device Drivers 3rd edition 
book).
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade
Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [ link to patch] resurrecting the uml-hcd

[James McMechan]

>From: Blaisorblade <blaisorblade@yahoo.it>
>To: user-mode-linux-devel@lists.sourceforge.net
>CC: "James McMechan" <james_mcmechan@hotmail.com>, 
>linux-usb-devel@lists.sourceforge.net
>Subject: Re: [uml-devel] [ link to patch] resurrecting the uml-hcd
>Date: Sun, 13 Aug 2006 13:24:28 +0200
>
>On Sunday 13 August 2006 06:10, James McMechan wrote:
> > I am attempting to resurrect the uml-hcd driver
> > this version is based off of the gadget/dummy_hcd.c driver.
> >
> > I am aiming at a 2.6.12.2 target where it will be used.
> > I have forward ported it to 2.6.17.6 for testing and hopefully
> > eventual inclusion.
> >
> > This patch has a #PLATFORM to deal with the issues between
> > 2.6.17.6/2.6.12.2 since platform_register... is not present in older
> > kernels and the new kernels don't work with the older registration.
>
>That's ok in drivers, however if at all possible have that in headers 
>rather
>than code (i.e. as CodingStyle says, it's better:
>#ifdef a
>#define func() func_old()
>#else
>#define func() func_new()
>#endif
>...
>func()
>
>rather than:
>
>#ifdef a
>	func_old();
>#else
>	func_new();
>#endif

No problem, I don't like it either, if the registration functions
still worked I would have kept using the old ones and defered the
platform update. this is the result of mad typeing to get the silly thing
working under 2.6.17

it is not too hard to just delete the !PLATFORM sections but I will
be needing them in 2.6.12 later so I had left them in
the struct redefs and function arg changes don't seem to fit well
into a header abstraction unless you want #RETURNVALUE1
#ARGLIST1 and simliar oddness.

If I understood you correctly my problem would be
in .h
#ifdef KERN2_6_17
#define func old_func
#else
#define func new_func
#endif
and in .c
#ifdef PLATFORM
new_return new_func(new_arg)
{}
#else
old_return old_func(old_arg)
{}
#endif
since the new and old version won't compile due to
renaming arguments and return values that don't exist
in the other version I think I would just end up duplicating
the code in a bigger ifdef.
>
> > For some reason the usb core is not sending hub urbs to my hcd
> > all the control seems to run through hub_control and hub_status_data
> > both of which are not checked before calling and so segfaults the kernel
> > if not present rather than queuing a control urb to get the
> > status as I would have expected...
> >
> > Now I realize, that in hub_control I can assemble a urb out of the data
> > presented and call my enqueue method, but it looks like that would
> > be unusually dense of me, since it appears that there should already be
> > some way to get the urbs.
> >
> > Notes:
> > I found that core/message.c does not include asm/scatterlist.h
> > it appears to assume that linux/pci.h has the scatterlist stuff,
> > but since UML has no PCI at all pci.h does not include it.
> > I just added the scatterlist.h
>
> > should I have removed pci.h?
>Not at all.

Well the comment suggests that the only reason it was present
was for the scatterlist functions ;)

>
> > On 2.6.17.6 it segfaults in the core at hub.c:2251 dev_dbg
> > where udev->bus->controller->driver->name is used without checking
> > if driver == NULL which it was in my version.  I have not figured out
> > where that driver is supposed to be set since the controller appears to
> > be created in the usb core somewhere...
> > This patch now checks for that.
>
> > Does anyone know where bus->controller->driver is supposed to be set?
>
>I'm seeing in your base driver this code:
>
>static struct platform_driver dummy_hcd_driver = {
>         .probe          = dummy_hcd_probe,
>         .remove         = dummy_hcd_remove,
>         .suspend        = dummy_hcd_suspend,
>         .resume         = dummy_hcd_resume,
>         .driver         = {
>                 .name   = (char *) driver_name,
>                 .owner  = THIS_MODULE,
>         },
>};
>.driver is a device_driver, and I suppose that 
>udev->bus->controller->driver
>should point to it (if you are building a driver for the controller, i.e. 
>the
>HCD driver).

yes, but I have set that one, and the problem does not occur under 2.6.12 
with
the same dev_dbg statement.

I have looked at this, the the udev was usb_alloc_dev from hub->hdev->bus
just before hub_port_init in hub_port_change which is called from hub_events 
from
hub_thread which is spawned at the start of usbcore and the hub device is 
now
automaticlly created from hdev from interface_to_usbdev(~current_altsetting) 
in
hub_probe called indirectly from the hub_driver.probe function pointer

I think it is a usb_bus *bus -> struct device *controller -> struct 
device_driver *driver
but for some reason a different driver...
just as a example I can add in uml_hcd_start

hcd->self.controller->driver=&uml_hcd_driver.driver;
which even works...

But I am pretty sure I am not supposed to do it like that.
is it even my driver or is it supposed to be the hub driver?

it is the only line in the entire drivers/usb tree that uses 
controller->driver
grep -r "controller->driver" linux-2.6.17.6/drivers/usb/
drivers/usb/core/hub.c:                 udev->bus->controller->driver->name,

It is a maze of calls and I have not been able to use breakpoints with gdb
much less the module symbols

I set the usual

b sys_init_module
b panic

and on modprobe I just get

[42949532.180000] Kernel panic - not syncing: Segfault with no mm
[42949532.180000]  [42949532.180000]
Program exited with code 01.
(gdb)


>
>I can provide a pointer to:
>http://lwn.net/Kernel/
>
>and some links you can find from it:
>
>http://lwn.net/Articles/driver-porting/
>http://lwn.net/Articles/2.6-kernel-api/
>http://lwn.net/Kernel/LDD3/ (the complete Linux Device Drivers 3rd edition
>book).
>--
>Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
>Paolo Giarrusso, aka Blaisorblade
>http://www.user-mode-linux.org/~blaisorblade
>Chiacchiera con i tuoi amici in tempo reale!
>  http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com

Thank you for your comments,
I may get arround to a non #PLATFORM edit later

Regards,

James McMechan



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [ link to patch] resurrecting the uml-hcd

[Blaisorblade]

On Sunday 13 August 2006 17:41, James McMechan wrote:
> >From: Blaisorblade <blaisorblade@yahoo.it>
> >To: user-mode-linux-devel@lists.sourceforge.net
> >CC: "James McMechan" <james_mcmechan@hotmail.com>,
> >linux-usb-devel@lists.sourceforge.net
> >Subject: Re: [uml-devel] [ link to patch] resurrecting the uml-hcd
> >Date: Sun, 13 Aug 2006 13:24:28 +0200

> No problem, I don't like it either, if the registration functions
> still worked I would have kept using the old ones and defered the
> platform update.

Don't worry, that's clear.

> this is the result of mad typeing to get the silly thing 
> working under 2.6.17
>
> it is not too hard to just delete the !PLATFORM sections but I will
> be needing them in 2.6.12 later so I had left them in
> the struct redefs and function arg changes don't seem to fit well
> into a header abstraction unless you want #RETURNVALUE1
> #ARGLIST1 and simliar oddness.
See the irqreturn_t definition - they suggest similar things indeed for 2.4 
compatibility (they suggest "add 
#if 2.4
#define irqreturn_t void
#define IRQ_HANDLED /**/
#endif
).

> If I understood you correctly my problem would be
> in .h
> #ifdef KERN2_6_17
> #define func old_func
> #else
> #define func new_func
> #endif
> and in .c
> #ifdef PLATFORM
> new_return new_func(new_arg)
> {}
> #else
> old_return old_func(old_arg)
> {}
> #endif
> since the new and old version won't compile due to
> renaming arguments and return values that don't exist
> in the other version I think I would just end up duplicating
> the code in a bigger ifdef.

I don't know the specific issue (i.e. how different are the two routines), my 
proposal was something like

#if LINUX_KERNEL_VERSION < ...
#define pci_init_driver pci_register_driver
#endif

or to have a micro-wrapper just for the changed thing. If the init is too 
different then ok - actually if you write with the #ifdef possibly when you 
merge you can remove it, and even if you keep it I don't think there will be 
too many objections.
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade
Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [ link to patch] resurrecting the uml-hcd

[Blaisorblade]

On Sunday 13 August 2006 17:41, James McMechan wrote:
> >From: Blaisorblade <blaisorblade@yahoo.it>
> >To: user-mode-linux-devel@lists.sourceforge.net
> >CC: "James McMechan" <james_mcmechan@hotmail.com>,
> >linux-usb-devel@lists.sourceforge.net
> >Subject: Re: [uml-devel] [ link to patch] resurrecting the uml-hcd
> >Date: Sun, 13 Aug 2006 13:24:28 +0200

> It is a maze of calls and I have not been able to use breakpoints with gdb
> much less the module symbols
For module debugging a very recent mail explained the solution in detail.
For break panic, it never worked for me - the suggestion is to add a pause() 
call in a loop checking a variable, and to change the var only in gdb; since 
such a var would be optimized out, add a global function called nowhere which 
sets that var too (on the list a more involved solution was proposed to stop 
the optimization but this should work).

> I set the usual
>
> b sys_init_module
> b panic
>
> and on modprobe I just get
>
> [42949532.180000] Kernel panic - not syncing: Segfault with no mm
> [42949532.180000]  [42949532.180000]
> Program exited with code 01.
> (gdb)

-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade
Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [linux-usb-devel] [ link to patch] resurrecting the uml-hcd

[Alan Stern]

On Sun, 13 Aug 2006, James McMechan wrote:

> I am attempting to resurrect the uml-hcd driver
> this version is based off of the gadget/dummy_hcd.c driver.
> 
> I am aiming at a 2.6.12.2 target where it will be used.
> I have forward ported it to 2.6.17.6 for testing and hopefully
> eventual inclusion.
> 
> This patch has a #PLATFORM to deal with the issues between
> 2.6.17.6/2.6.12.2 since platform_register... is not present in older
> kernels and the new kernels don't work with the older registration.
> 
> For some reason the usb core is not sending hub urbs to my hcd
> all the control seems to run through hub_control and hub_status_data
> both of which are not checked before calling and so segfaults the kernel
> if not present rather than queuing a control urb to get the
> status as I would have expected...

No.  These function pointers _must_ be set.

There's no point queuing an URB for the root hub.  Queued URBs are sent 
out over the USB bus... which makes no sense when the URB's destination is 
the HCD itself.

Or to put it another way: Why should an HCD have to work to unpack the 
request, request type, value, index, and length fields from the URB when 
usbcore has already done all that?  It's simpler to pass the values 
directly to a hub_control method than to force every HCD to repeat this
work.

> Now I realize, that in hub_control I can assemble a urb out of the data
> presented and call my enqueue method, but it looks like that would
> be unusually dense of me, since it appears that there should already be
> some way to get the urbs.

It is indeed possible to get at the original control URB.  Just follow the
linked list in hcd->self.root_hub->ep0.urb_list; there should be only one
entry in the list and it will be the URB.

> On 2.6.17.6 it segfaults in the core at hub.c:2251 dev_dbg
> where udev->bus->controller->driver->name is used without checking
> if driver == NULL which it was in my version.  I have not figured out
> where that driver is supposed to be set since the controller appears to
> be created in the usb core somewhere...
> This patch now checks for that.
> 
> Does anyone know where bus->controller->driver is supposed to be set?

It gets set when your HCD is bound to the platform device.  In dummy_hcd.c 
this occurs in the initialization routine, where the code calls

	retval = platform_driver_register (&dummy_hcd_driver);
	...
	retval = platform_device_register (&the_hcd_pdev);

This causes the driver core to set the_hcd_pdev.dev.driver equal to 
&dummy_hcd_driver.driver.  In your code this mechanism doesn't work 
because the names don't match: Your device's name is "uml-hcd" with a '-' 
and your driver's name is "uml_hcd" with an '_'.

> uml-hcd is currently partly operational
> I can enumerate the device, libusb will talk to it.
> Control URBs seem to go back and forth.
> and report status back correctly.
> 
> I have walked through the usbmon output on the host and the hub simulation
> is producing the same status in the same order as the host does
> the host appears to produce urbs for its root hub however.
> under uml usbmon does not show up in /sys/kernel/debug so
> I have not been able to test it there, my current spew level dev_info dumps
> all the hub control/status to my console.

Doesn't uml implement the debugfs filesystem?  Did you remember to set 
CONFIG_DEBUG_FS and to do "mount -t debugfs none /sys/kernel/debug"?

> Your thoughts are welcome, I would hate to have to fall back to creating a
> virtual proc files system that just forwards all the libusb calls down to 
> the
> host OS.  This was working a few years ago and it looks (from dummy_hcd.c
> and usbip) that it should be possible here. I know it was possible to write
> a complete usb from userspace without requiring a stub driver back in
> the bad old days of 2.4.18...
> 
> No doubt this version takes may liberties with the core and driver model
> if you could point out some of the more obvious ones to me,
> I still was thinking about the automatic interrupt urb submission when last
> this was current.

On a quick glance, it appears that your dequeue method does not try to 
cancel the URB on the host.  Shouldn't it do so?

> The patch can be fetched from 
> http://mysite.verizon.net/james.mcmechan/uml-hcd.2.6.17.6.patch
> or bzipped as 
> http://mysite.verizon.net/james.mcmechan/uml-hcd.2.6.17.6.patch.bz2
> it is 1104 lines long & 31K in size so I stuck it on a web page.

Your server doesn't set the MIME type correctly; everything appears to be 
text/html or something similar.

Alan Stern


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel