Need help to get udev/hotplug working for extra module in early 2.6

Need help to get udev/hotplug working for extra module in early 2.6

[Martin Burnicki]

Hi all,

I'm maintaining a driver for Meinberg PCI cards (radio clocks, GPS
receivers, IRIG receivers), see "Standalone Computer Synchronisation":
http://www.meinberg.de/english/products/formfactor.htm#slot_card

The driver lets the ntpd daemon be able to use those PCI cards as
plugged-in reference time sources for accurate timing.

The driver package contains an extra module which is built outside the
kernel tree. The currently released version of the driver can be built
and used with kernels 2.2.x, 2.4.x, and 2.6.x.

However, that version of the driver implements a "misc" device in a way
which doesn't support 2.6's udev very well.

I've now improved the code of the kernel module (currently for 2.6.x
only) and the new module works fine under recent 2.6.x kernels, e.g.
2.6.11 (SuSE 9.1 on i386), 2.6.22 (Ubuntu on Sparc64), or 2.6.25
(openSUSE 11 on AMD x86_64).

The new driver implements a new class of character device, mbgclock,
which uses a dynamic major number. Additionally the driver supports our
new USB devices in a way they can be accessed by applications using the
same API calls as with PCI cards.

Under the newer 2.6.x kernels, if a PCI card is installed or when a new
USB radio clock is plugged in my kernel module is loaded automatically,
and the device nodes are created or deleted by udev as required, so
everything works fine.

Now I'd like to get some help to get it working on older 2.6.x kernels.

E.g. I have a SuSE 9.1 system with 2.6.4 kernel. After booting, my
kernel module is not loaded automatically even though a PCI card is
installed. If I load the module using modprobe then the PCI card is
recognized and works just fine.

If I plug in a USB device, or the USB device is already plugged in at
boot time, then the module is loaded automatically.

However, device nodes are never created automatically on that 2.6.4
system, so I have to create them the old way using mknod. So they are
even persistent over reboots, as they have been with older kernels.

Unfortunately, since the driver now uses a dynamic major number I would
normally have to load the module first, then look in /proc/devices which
major number has been assigned to my device class, and finally create
the device nodes using that major number.

So the best way to get it working would be as with recent kernels.

I'm assuming the udev actions are triggered by class_simple_device_add()
 (before 2.6.13) or class_device_create() (2.6.13 and newer). Is it
possible that I have to call some extra function in 2.6.4 to trigger a
udev or hotplug event in 2.6.4 so a device node gets created?

Unlike with newer systems where udev is configured using multiple rules
files in /etc/udev/rules.d the 2.6.4 system has only a single rules
file, namely /etc/udev/udev.rules.

Is there someone who is familiar with the history of udev/hotplug who
can point me in the right direction?


Thanks,

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Re: Need help to get udev/hotplug working for extra module in early

[Martin Burnicki]

Hi,

nobody here who can give me a hint? Should I ask this on the kernel
mailing list instead?

Martin

On Tue, 08 Jul 2008 16:24:29 +0200 Martin Burnicki wrote:
> Hi all,
> 
> I'm maintaining a driver for Meinberg PCI cards (radio clocks, GPS
> receivers, IRIG receivers), see "Standalone Computer Synchronisation":
> http://www.meinberg.de/english/products/formfactor.htm#slot_card
> 
> The driver lets the ntpd daemon be able to use those PCI cards as
> plugged-in reference time sources for accurate timing.
> 
> The driver package contains an extra module which is built outside the
> kernel tree. The currently released version of the driver can be built
> and used with kernels 2.2.x, 2.4.x, and 2.6.x.
> 
> However, that version of the driver implements a "misc" device in a way
> which doesn't support 2.6's udev very well.
> 
> I've now improved the code of the kernel module (currently for 2.6.x
> only) and the new module works fine under recent 2.6.x kernels, e.g.
> 2.6.11 (SuSE 9.1 on i386), 2.6.22 (Ubuntu on Sparc64), or 2.6.25
> (openSUSE 11 on AMD x86_64).
> 
> The new driver implements a new class of character device, mbgclock,
> which uses a dynamic major number. Additionally the driver supports our
> new USB devices in a way they can be accessed by applications using the
> same API calls as with PCI cards.
> 
> Under the newer 2.6.x kernels, if a PCI card is installed or when a new
> USB radio clock is plugged in my kernel module is loaded automatically,
> and the device nodes are created or deleted by udev as required, so
> everything works fine.
> 
> Now I'd like to get some help to get it working on older 2.6.x kernels.
> 
> E.g. I have a SuSE 9.1 system with 2.6.4 kernel. After booting, my
> kernel module is not loaded automatically even though a PCI card is
> installed. If I load the module using modprobe then the PCI card is
> recognized and works just fine.
> 
> If I plug in a USB device, or the USB device is already plugged in at
> boot time, then the module is loaded automatically.
> 
> However, device nodes are never created automatically on that 2.6.4
> system, so I have to create them the old way using mknod. So they are
> even persistent over reboots, as they have been with older kernels.
> 
> Unfortunately, since the driver now uses a dynamic major number I would
> normally have to load the module first, then look in /proc/devices which
> major number has been assigned to my device class, and finally create
> the device nodes using that major number.
> 
> So the best way to get it working would be as with recent kernels.
> 
> I'm assuming the udev actions are triggered by class_simple_device_add()
>  (before 2.6.13) or class_device_create() (2.6.13 and newer). Is it
> possible that I have to call some extra function in 2.6.4 to trigger a
> udev or hotplug event in 2.6.4 so a device node gets created?
> 
> Unlike with newer systems where udev is configured using multiple rules
> files in /etc/udev/rules.d the 2.6.4 system has only a single rules
> file, namely /etc/udev/udev.rules.
> 
> Is there someone who is familiar with the history of udev/hotplug who
> can point me in the right direction?
> 
> 
> Thanks,
> 
> Martin


-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Re: Need help to get udev/hotplug working for extra module in

[Greg KH]

On Tue, Jul 15, 2008 at 12:21:14PM +0200, Martin Burnicki wrote:
> Hi,
> 
> nobody here who can give me a hint? Should I ask this on the kernel
> mailing list instead?

Probably no one really cares about such old and unmaintained systems
anymore, sorry.

It all really depends on how the specific distro implemented their /dev
system.  We did a lot of work to get everyone to standardise, and here
you are asking us to remember years ago when everything was a mess.

Most of that is lost in a drunken haze, thankfully :)

Sorry, you are on your own here.

good luck,

greg k-h

Re: Need help to get udev/hotplug working for extra module inearly

[Greg KH]

On Thu, Jul 17, 2008 at 09:39:36AM +0200, Holland, John wrote:
> > > Hi,
> > >
> > > nobody here who can give me a hint? Should I ask this on the kernel
> > > mailing list instead?
> >
> > Probably no one really cares about such old and unmaintained systems
> > anymore, sorry.
> 
> That's not necessarily true. Many embedded systems continue to use older
> kernels, even for new development. The devices with which I'm continually
> confronted, use kernels 2.6.1[23] the newest of which is 2.6.19.

And that's their own fault, the kernel community has long had the
opinion that this is not a good thing to do.

If you are using such a kernel, then you need to rely on the support
from your vendor, the community can't help you out, sorry.

> You may want to check out mdev of a recent busybox version.

I don't see how that is relevant to the issue addressed here.  mdev is
just what udev was 2-3 years ago, nothing more.

thanks,

greg k-h

Re: Need help to get udev/hotplug working for extra module

[Greg KH]

On Thu, Jul 17, 2008 at 11:24:31AM +0200, Holland, John wrote:
> 
> > > > Hi,
> > > >
> > > > nobody here who can give me a hint? Should I ask this on the kernel
> > > > mailing list instead?
> > >
> > > Probably no one really cares about such old and unmaintained systems
> > > anymore, sorry.
> >
> > That's not necessarily true. Many embedded systems continue to use older
> > kernels, even for new development. The devices with which I'm continually
> > confronted, use kernels 2.6.1[23] the newest of which is 2.6.19.
> >
> > And that's their own fault, the kernel community has long had the
> > opinion that this is not a good thing to do.
> >
> I agree, new development should be made with new kernels. But that's
> not always economical. And being linux is becoming more main stream
> and that some embedded devices have a long life cycle it may be
> advantageous to be little more accommodating.

The longer that Linux has been around, the larger the ammount of old
code we would have to support, right?  Where is the fair cut-off point
for the community to support their old releases for free?

It's a tough issue, but usually it only affects the last realease or so,
not stuff 3-5 years ago.

And again, this is a distro specific issue, dealing with how that distro
set up udev and hotplug at the time.  Odds are no one here even was
involved in that (I sure wasn't).

> > If you are using such a kernel, then you need to rely on the support
> > from your vendor, the community can't help you out, sorry.
> At one point in time that kernel was current.
> Is there a time line describing the correlation of kernel version
> to udev version(s)?

A loose one can be found in the Documentation/Changes file, listing the
minimum required version of udev for the kernel.

But again, that's not the issue here.

> When does support for a given udev version expire?

Same as any open source project, when a new release happens or so.

> Where can I find recent udev documentation?

In the udev source code tree.

> > > You may want to check out mdev of a recent busybox version.
> >
> > I don't see how that is relevant to the issue addressed here.  mdev is
> > just what udev was 2-3 years ago, nothing more.
> The mdev's scanning algorithm is much easier to manipulate than that
> of udev.

That's an odd term, given that there is no "scanning algorithm" in udev
at all, we rely on the kernel to provide the events and act apon them,
that's the whole point of the model.

thanks,

greg k-h

Re: AW: Need help to get udev/hotplug working for extra module inearly2.6

[Martin Burnicki]

Greg, John,

first of all thanks for your replies.

Holland, John schrieb:
>> > > Hi,
>> > >
>> > > nobody here who can give me a hint? Should I ask this on the kernel
>> > > mailing list instead?
>> >
>> > Probably no one really cares about such old and unmaintained systems
>> > anymore, sorry.

Oh I thought someone who is closely involved

>> That's not necessarily true. Many embedded systems continue to use older
>> kernels, even for new development. The devices with which I'm continually
>> confronted, use kernels 2.6.1[23] the newest of which is 2.6.19.

Many of our customers buy PCI cards for existing systems, and they often
ask whether a specific version of the kernel or of a distribution is
supported, and there are also versions based on older kernels.

They often don't upgrade their systems unless really necessary ("never
touch a running system"), and I do understand their reasons for this.

For example, our company and many of our customers are working with high
accuracy timing, and when the new Linux clock model was introduced (I
think around 2.6.20) there were lots of problems with timer devices in
specific mainboard chipsets, or with the drivers for those timers. Don't
misunderstand me, the new clock model is great, but when it had just
been introduced there were many problems with accurate timekeeping.

I'm also loosely involved in the development of NTP (burnicki@ntp.org)
and there have been many discussions in the NTP news groups why those
kernel versions have been unable to keep time properly. So if someone
does not immediately use the latest kernel I understand that.

>> And that's their own fault, the kernel community has long had the
>> opinion that this is not a good thing to do.
>>
> I agree, new development should be made with new kernels. But that's
> not always economical. And being linux is becoming more main stream
> and that some embedded devices have a long life cycle it may be
> advantageous to be little more accommodating.

Once more agreed. However, this is not only true for embedded systems
but also for normal PCs which just keep on doing their work perfectly
for a long time.

>> If you are using such a kernel, then you need to rely on the support
>> from your vendor, the community can't help you out, sorry.
> At one point in time that kernel was current.
> Is there a time line describing the correlation of kernel version
> to udev version(s)? When does support for a given udev version
> expire? Where can I find recent udev documentation?

I absolutely agree.

My driver's source code basically cares about all kernel API changes it
needs to care for, and as already mentioned earlier, it already works on
old and new 2.6.x kernels except for creation of devices nodes, which
works perfectly automatically with recent kernels but requires manual
intervention with older 2.6.x kernels.

There's lots of information how to write kernel drivers for specific
kernels, and there's lots of information about udev, but I have not
found many information of the interaction between specific kernel
versions and specific udev versions.

If you are writing a kernel driver which is not strongly bound to a
specific kernel version than the following article is really great:
http://lwn.net/Articles/2.6-kernel-api/

A similar article for udev would also be great, and even better if the
interaction between specific kernel API calls and udev and their history
would be explained a little more detailed.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Re: Need help to get udev/hotplug working for extra module inearly2.6

[Martin Burnicki]

Greg,

Greg KH wrote:
> ..., we rely on the kernel to provide the events and act apon them,
> that's the whole point of the model.

Yes, however it may be possible that in recent kernels a certain kernel
API function e.g. class_device_create() creates a device object and also
generates an udev event whereas in older kernels you had to call 2
kernel API functions.

I'm maintaining our driver for many years now and remember the basic
improvements over the years, or limitations of older versions. Since
some of you guys here are also involved in the development of udev and
kernel drivers I was hoping someone could just give me a raw hint what
needed to be done with the older kernel API which isn't required nowadays.


Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany