On Mon, September 30, 2002 at 2:49 AM, Russell King wrote:
> On Mon, Sep 30, 2002 at 10:40:12AM +0100, Tim Waugh wrote:
> > On Thu, Sep 26, 2002 at 10:05:16PM +0200, Marek Michalkiewicz wrote:
> > > below is a patch that moves parport_serial.c from drivers/parport/
> > > to drivers/char/ - this fixes the wrong link order when the
> > > drivers are compiled into the kernel.
> >
> > What was wrong with the original, much smaller patch that you sent
> > me previously (below)?
> >
> > I'm happy to accept whichever patch is the better.
>
> Other than it's a gross hack rather than a fix. However, for 2.4, I
> think this is probably the best solution without creating a risk of
> other init ordering problems. Ed, any comments?
>
Hi Russell,
I agree. For 2.4, Stability before elegance. Minimum change is a good thing.
The patch looks straight-forward enough, simply plop the file into a
directory for which it was never intended. It does localize the effect of
the change nicely.
I have a question. Similar changes have been suggested several times and
always seem to bring out a small hail of rather negative comments. (like
"gross hack ..." :)
Are there any hidden issues with the patch? That is, beyond the decrease in
maintainability? I didn't see anything relevant to this technique in the
lkml archive. I'm a little wary of anything that gets an "oh no, not this
again" reaction. Hmmm... I think I hear the distant sound of arrows being
sharpened.
Best regards,
Ed
----------------------------------------------------------------
Ed Vance serial24 (at) macrolink (dot) com
Macrolink, Inc. 1500 N. Kellogg Dr Anaheim, CA 92807
----------------------------------------------------------------
> I agree. For 2.4, Stability before elegance. Minimum change is a good thing.
> The patch looks straight-forward enough, simply plop the file into a
> directory for which it was never intended. It does localize the effect of
> the change nicely.
Yes, moving parport_serial looked much simpler to me than moving serial
to its own directory (the proper solution, done in 2.5). I hope others
can also agree to accept this low risk change for 2.4 in the meantime.
In some sense, parport_serial is not strictly part of neither serial nor
parport drivers - it is common to (uses the services of) both.
> I have a question. Similar changes have been suggested several times and
> always seem to bring out a small hail of rather negative comments. (like
> "gross hack ..." :)
Well, the hardware itself is kind of a hack (not a clean design - no
separate PCI functions for serial and parallel ports; I guess that would
use a little more silicon and make the chip a few cents more expensive),
and that's the reason why the parport_serial driver exists at all...
Thanks,
Marek
Hi,
here are the parport_serial / NM9835 patches, updated for 2.4.20-pre9:
http://www.amelek.gda.pl/linux-patches/2.4.20-pre9/00_parport_serial
http://www.amelek.gda.pl/linux-patches/2.4.20-pre9/01_netmos
http://www.amelek.gda.pl/linux-patches/2.4.20-pre9/02_sagatek
Please apply in this order, 00_parport_serial then 01_netmos.
00_parport_serial is big because it moves parport_serial.c to
a different directory (but no single line in that file is changed).
01_netmos adds NetMos PCI multi I/O support, tested on NM9835 and
working fine in two (soon three) machines here. So I removed the
"not tested" comments from the NM9835 lines of the original patch.
In addition to the two patches, you get the third one (02_sagatek)
for FREE :) - it is independent of the two, and adds support for
a buggy USB/CompactFlash adapter, known under 3 different names:
Datafab KECF-USB, Sagatek DCS-CF, Simpletech Flashlink UCF-100
(I have the Sagatek DCS-CF, others tested by two other people).
These are the patches I apply to every kernel I build (to support
my hardware), in addition to the usual i2c and lm_sensors patches.
Thanks,
Marek