Re: [cbm4linux-users] Problems with cbm4linux

[Dirk J. <do...@cu...>]

Hello Spiro,

> Speaking of these patches: What benefit do you get dropping support for
> pre-2.6 kernels? To me, it seems large parts of your patches are just
> throwing out the 2.4, 2.2 and 2.0 support.

My personal view ist, that kernels < 2.2 are now obsolete and I find it 
really cluttering to have the code support them anymore. If you really 
want to use such a kernel you can take any of the released cbm4linux 
version which still support them.
As cbm4linux is not the first kernel driver code I looked at/worked on I 
can tell from my experience that's it's no benefit to try to maintain 
different kernel versions/API within the same source code as it just 
messes up and complicates with each new kernel revision. The kernel API 
change and they change for a reason, which is mostly enhanced 
functionality or portability or performance or whatever.
I see my patch just as an offer how the code of official releases might 
be changed. If the majority want to include support for multiple major 
kernel releases in one sourcecode I'll accept that. But if you seriously 
ask what kernel versions your users nowadays use I'll bet you don't get 
(m)any answers for kernel < 2.4, so you could just drop the code and 
have a leaner codebase for future developments.

> For the "RESET FIX": The waiting time has a reason. If you issue a
> reset, but do not wait any time, you can get very annoying results. To
> avoid confusion, reset waits 5 seconds. Thinking about anything but a
> 1541 with -01 or -03 ROMs, this time might be a little bit high. For the
> 1541 with -01 or -03 ROM, this time might be more appropriate.

I changed this, because with floppy drive doesn't need any reset wait 
(at least for my simple d64copy actions I do). And my patch makes the 
reset wait configurable. If you want to stay on the safe side you could 
set the default value to 5 again and the behaviour would be the same as 
before. Just that it can now be changed by a simple module loading option.

> Hu? AFAIR, even "stock" cbm4linux uses these modules if the kernel
> supports them. Fortunately, without your patches, c4l uses the old
> implementation if these are not supported.

But this is only true for x86 equiped with standard parallel ports. The 
kernel parport api exists for a reason and my view is that it should be 
used if you have devices attached to the parallel port. I haven't tested 
it, but when using the parport api the cbm4linux code should be portable 
to every architecture linux supports that features some kind of parallel 
port.

-- 
---> doj / cubic
----> http://cubic.org/~doj
-----> http://llg.cubic.org