[PLUG] USB and /dev/usb/lp0

[Shannon C. Dealy]

On Sat, 6 Jul 2002, Bill Spears wrote:

[snip]
> You were right 'printer' is all it took.
> Many thanks.

You're welcome.

> >From your sig, you might be a good guy to explain this.
> I can see that /dev/foo is kind of like a place holder. In my case,   I could
> have made mine by mknod  /dev/usb/lp0 c 180 0.

> How does the rest of the system connect to this dev

By rest of the system, I assume you mean application software?  UNIX/Linux
systems generally take the approach of making everything look like a file,
so for application code, it simply uses a standard "open" subroutine call
to open the device just like any other file (the kernel uses the major
device ID to map the "open" to the correct driver), and the data is
read/written the same as it would be for any other file.  For handling
specialized I/O needs which are device specific (or in some cases
specialized extended file operations for regular files), there is a
standard function "ioctl" which is called to perform these operations on
the device/file, though since the needs of each device are generally
different, there is only limited standardization of the functionality of
commands issued using ioctl.  There have been various attempts over the
years to pull out standard functionality from ioctl in order to make
software more generic and portable, but it has had only limited success.

> Are the major,minor nos. in the driver code?

Yes, sort of.  For most standard devices, there is a predefined major
device number which is hard coded (usually as a #define in a header file)
into the device driver, and the mapping to the device driver comes not
from the file name of the device file, but from it's major and minor
device numbers.  The minor device number is just passed to the device
driver that corresponds to the major devices number, and is typically used
to denote which device, since the same driver may be used for a number of
different devices in a particular class (such as serial ports).  While
this is typical use for the minor number, it's use is actually undefined
and it can be used for any purpose.

Just for the sake of muddying the waters :-) non-standard/custom devices
can dynamically allocate their major device numbers at run time, and the
devfs file system introduced with the 2.4 kernels I believe intends to
make all major device numbers as well as the device files themselves,
dynamically created (and destroyed) at run time.  I have only glanced over
this stuff so I don't really know any details, since no one has hired me
to do a Linux device driver so far, and I haven't had any reasons to
modify or create any Linux device drivers on my own for several years.

> And I needed both usb-ohci and printer.  How does that work? They're not
> dependent on each other as modules are they?
[snip]

Without taking the time to look at this specific case (i.e. I may be
wrong on some technicality, but overall this should be correct :-)
printer is probably dependent on usb-ohci, the printer driver is
specifically a USB printer driver, so it needs a USB interface to
provide it's communication link to the printer in order to do anything,
and this functionality would be provided by the usb-ohci driver.  Of
course this doesn't work both ways, there is no reason for the usb-ohci
module to depend on the printer module, since it doesn't really care what
devices are out on the bus, it simply provides the communication channel
to them.  A quick look at my own system does show that usb-ohci is
dependent on usbcore however, which is a common set of USB related
subroutines that most USB drivers would likely need.


Shannon C. Dealy      |               DeaTech Research Inc.
dealy at deatech.com     |          - Custom Software Development -
                      |    Embedded Systems, Real-time, Device Drivers
Phone: (800) 467-5820 | Networking, Scientific & Engineering Applications
   or: (541) 451-5177 |                  www.deatech.com