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@xxxxxxx)
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
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
