RE: Need persistent node to USB port naming

["Stephen Morgan" <stephenm@glw.com>]

On Mon, May 16, 2005 at 9:56 AM, Greg KH wrote:
> On Mon, May 16, 2005 at 10:40:40AM -0500, Stephen Morgan wrote:
> > > On Sat, May 14, 2005 at 12:04 AM, Greg KH wrote:
> > > On Fri, May 13, 2005 at 06:29:16PM -0500, Stephen Morgan wrote:
> > > >On Fri, May 13, 2005 at 12:55 PM, Greg KH wrote:
> > > >> On Fri, May 13, 2005 at 11:55:05AM -0500, Stephen Morgan wrote:
> > > >>> One problem I've run into is trying to create a dummy node
> > > that allows me to
> > > >>> communicate with the driver thru ioctl's even when no device
> > > is plugged in.
> > > >>> In 2.4, I just created a node with a minor I knew would never
> > > be used, and
> > > >>> in the driver, I filtered for that minor.
> > > >
> > > > Any thoughts on how to create this dummy device node?
> > >
> > > Um, I can't recommend _ever_ doing this kind of thing.
> > >
> > > That being said, what do you want to get to and from the driver?
> >
> > It's mostly useful during development.  For instance, I can change the
> > driver's debug print priority on the fly.
>
> That is useful.  So useful that if you look at any usb-serial driver,
> they already do this in the /sys/modules/MODULE_NAME/paramaters/debug
> file :)

I guess I'm missing something here.  What should I be looking for (I assume
in /drivers/usb/serial/)?

In usb-serial.h, I see your dbg macro, which has a fixed priority of
KERN_DEBUG and can be turned on and off with the 'debug' variable.

I'm using ...

#define dbug(level, format, arg...) do { if (debug & level)
printk(KERN_NOTICE __FILE__ ": " format "\n" , ## arg); } while (0)

... so each call can use one of several values of "level", and by passing
"debug" in through an ioctl(), I have pretty good control over printk
traffic, assuming I chose my levels wisely.

>
> You can get this for free too with the module_param() macro.

But, isn't that only able to set the parameter once, at load time?

>
> > Eventually, I'll use it to retrieve diagnostic info the driver is
> > collecting.
>
> sysfs is for 1 value per file.  For diagnostic information, I suggest
> using debugfs instead, that is what it is there for.

Can you recommend a good reference on debugfs?  The only thing I've found is
the man page that calls it "an interactive file system debugger."

>
> > > Why not just use sysfs files that you put in your driver's
> directory?  That
> > > is what they are there for :)
> >
> > Okay, I'm not sure what you just said, so I'm gonna go read sysfs.txt.
>
> Try the Third Edition of Linux Device Drivers from Oreilly.  It's much
> better than that outdated file.  It's also online for free if you don't
> want to buy it.

Okay, thanks.  I've got that now.

>
> Good luck,
>
> greg k-h
>



-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_idt12&alloc_id\x16344&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel