RE: [patch] fix parport_serial / serial link order (for 2.4.20-pr e8)

RE: [patch] fix parport_serial / serial link order (for 2.4.20-pr e8)

[Ed Vance]

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
----------------------------------------------------------------

Re: [patch] fix parport_serial / serial link order (for 2.4.20-pr e8)

[Marek Michalkiewicz]

> 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

Re: [patch] fix parport_serial / serial link order (for 2.4.20-pr e8)

[Marek Michalkiewicz]

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