AW: PCMCIA patches - unsuccessful so far

[Pavel Roskin]

> I definitiely do not want to break that much before 2.6.0, but I want to
> make it easier to support new drivers (which won't need changes in
> /etc/pcmcia/ any more) and clean up the core (locking, CodingStyle,
> functionality, bugs, etc.) -- by incremental patches, so that we won't
> have to argue about inclusion of "one big patch" even during the next
> development cycle.

I'm all for incremental patches.

> And my sysfs_resource patch really doesn't _change_ anything we do wrt
> resources; just the way the information is passed from user- to
> kernelspace.

Then maybe your script should process /etc/pcmcia/config.opts?

> However, the sysfs interface (which I needed to show that cardmgr is not
> needed any longer) will be dropped for 2.5.68 - so no need to argue about
> it any longer :)

Fine with me either way.

> > 1) Development cycle.  Not everybody wants to way years for the next
> major
> > kernel release to make a major overhaul.
>
> I guess I'm preaching to the choir here, but:
>
> Drivers are updated much more regularly, just the core interfaces tend to
> stay the same... and external drivers still use the pcmcia-cs package, I
> suspect, which hasn't had big changes in many months....

OK, maybe my reference to the development kernels wasn't justified.  But
let's imagine following scenario.

Driver foo-0.1 (very buggy and ineffective) goes to Linux 2.4.17 (released
22-Dec-2001).  Red Hat releases version 7.3 with kernel 2.4.18 and that
driver.  50% of Red Hat users won't ever recompile any kernel code, but
some of them would complain to the mailing list for that driver.

In the meantime, much more stable foo-0.6 is released.  It's included into
2.4.21-pre5.  Even better driver foo-0.7 is included into 2.4.21-pre7-ac1.

At this point, a fatal bug is discovered in versions 0.1-0.7 that would
permanently destroy the hardware with some probability (e.g. once for 1000
initializations).  Version 0.8 is released immediately.  But how do you
update the driver for everybody?

Marcelo won't release 2.4.21 just for that reason.  There were more
serious cases when he should have made a release but he didn't.

Many users won't use any "-pre" kernel, let alone "-ac".  Many Red Hat
users won't use stock kernels.

Either the driver team should create binary packages for every
distribution and every kernel update, or it should provide a way for the
users to compile the driver against the existing kernel.

Including a driver into the kernel is a huge responsibility, and not
everybody wants to take it, especially on the early stages of development.

There should be an easy way to compile drivers outside the kernel tree.

-- 
Regards,
Pavel Roskin