Re: [cbm4linux-users] Problems with cbm4linux

[Spiro T. <tri...@gm...>]

Hello Dirk,

* On Thu, Jul 14, 2005 at 01:00:16PM +0200 Dirk Jagdmann wrote:
 
> 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 long as it does not take considerable time and work to keep
compatible with older versions, I do not see any reason to drop support.
WHEN it will become time-consuming to support them, let's drop it, but
not before, please.

I hope Michael has the same point. In fact, I believe so as otherwise,
most probably, he would have dropped it long before.


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

One could come to the conclusion that these always changing APIs do no
good. It is the Linux' way to force people keeping up.

Unfortunately, I will not consider upgrading my small 486DX4-100 server
to a 2.6 kernel as long as my 2.2 kernel runs there.

> I see my patch just as an offer how the code of official releases
> might be changed.

Personally, I'd like it if you could try to keep them more separate. You
want to remove things with a patch: Then make a patch which only does
this, nothing more.

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

Ok, here one side note:

Michael and me, we are currently looking into integrating cbm4linux and
cbm4win back into one source. In fact, we are in a state that both
compile flawlessly out of one source, but we have not release yet. It
might be a good time to do so when we have joined both SF projects into
one, which we are planning.

As Michael has no means to test the Windows code, this "cross-testing"
is mostly my task. As I do own some Linux machines, I want to be able to
test the Linux code, too.

Personally, I do not have any 2.6 kernel machine (other than something
on VMWare), and only have one machine where a 2.4 kernel runs on. Thus,
I am mainly testing on a 2.2 kernel.

If the support for < 2.4 is dropped, it will be hard for me to be able
to test both variants. Anyway, I would like to be able to do this, as
this could help in finding problems. Furthermore, I can test that my
changes do not break Linux.



[RESET FIX]

> I changed this, because with floppy drive doesn't need any reset wait 
> (at least for my simple d64copy actions I do).

You are just lucky that you are not too fast. In fact, this waiting time
*is* necessary. I have "tested" this accidentially more than once. See
also Joe's comment.

In fact, I wanted to remove this 5 sec delay from cbm4win until I found
out that there is a reason for it.

Of course, having it configurable is a good choice. In fact, in cbm4win,
it already is (from the first initernal version in 2001).

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

It is not that I dislike this patch. I just wanted to warn about the
implications which you might not know about.

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

Again, you want to break compatibility without a reason (at least, I do
not see any).

This code does not do any harm, so, why remove it?

BTW: The "no-parport-code" is easier to debug than the parport-code.


With all your reasoning, if I would think as you, there would be no
reason to try to support Win 98 (which would be new) or Win NT 4.0
(which is already there) in cbm4win. I think this would be a pita.

Regards,
   Spiro.

-- 
Spiro R. Trikaliotis
http://www.trikaliotis.net/
http://cbm4win.sf.net/