Thread: Re: Sv:Re: [cbm4linux-users] Problems with cbm4linux
Brought to you by:
cbm4linux
Menu
▾
▴
cbm4linux-users
|
From: Dirk J. <do...@cu...> - 2005-07-14 10:02:31
|
> [thomas@localhost ~]$ uname -a > Linux localhost.localdomain 2.6.12-1.1390_FC4 #1 Tue Jul 5 19:58:55 EDT 2005 i686 athlon i386 GNU/Linux As you're using a 2.6 kernel I suggest you try my patches for cbm4linux and linux 2.6. They're available here: http://sourceforge.net/tracker/?group_id=45917&atid=444478 They then use the generic parport modules from linux, so you should have parport and parport_pc as kernel modules too. -- ---> doj / cubic ----> http://cubic.org/~doj -----> http://llg.cubic.org |
|
From: Dirk J. <do...@cu...> - 2005-07-18 20:35:14
|
> I think I found out what my problem was, but I have not figured a solution. According to the Fedora Core 3 document: > http://www.lb.shuttle.de/puffin/cbm4linux/cbm4linux-for-FC3.txt > > I should edit /etc/udev/permissions.d/50-udev.permissions > > But there is no permissions.d directory in Fedora Core 4. I assumed I could just create the directory, but I guess I might be wrong. Does anybody know how to set these permissions in Fedora Core 4? But there should be a /etc/udev directory. Tell me the contents of your directory and I might suggest a place to add it. -- ---> doj / cubic ----> http://cubic.org/~doj -----> http://llg.cubic.org |
|
From: Spiro T. <tri...@gm...> - 2005-07-14 10:34:53
|
Hello Dirk, * On Thu, Jul 14, 2005 at 12:02:26PM +0200 Dirk Jagdmann wrote: > As you're using a 2.6 kernel I suggest you try my patches for > cbm4linux and linux 2.6. They're available here: > http://sourceforge.net/tracker/?group_id=45917&atid=444478 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. 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. > They then use the generic parport modules from linux, so you should > have parport and parport_pc as kernel modules too. 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. Regards, Spiro. -- Spiro R. Trikaliotis http://www.trikaliotis.net/ http://cbm4win.sf.net/ |
|
From: Joe Forster/S. <st...@c6...> - 2005-07-14 10:45:48
|
Hi guys, > 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. Just to clear things up: unless you wait for the drive to finish its=20 reset sequence _before_ you (try to) communicate with it, the drive will=20 get stuck in an endless loop. You will have to reset it again and be more= =20 patient this time. ;-) > To avoid confusion, reset waits 5 seconds. The Star Commander keeps trying to detect the presence of devices (mostly= =20 a contribution by WoMo). A nice side effect of this is that the Commander= =20 can catch the exact moment when the drive finishes the reset sequence so=20 the delay is as short as possible. Spiro, contact me if you'd like to embed it into cbm4linux; I'll point=20 you to the respective code in the Commander source. Bye, Joe --=20 KOV=C1CS Bal=E1zs alias Joe Forster/STA st...@c6...; http://sta.c64.or= g Don't E-mail spam, HTML or uncompressed files! More contacts on homepage |
|
From: Spiro T. <tri...@gm...> - 2005-07-14 12:11:52
|
Hello Joe, * On Thu, Jul 14, 2005 at 12:45:33PM +0200 Joe Forster/STA wrote: > Just to clear things up: unless you wait for the drive to finish its > reset sequence _before_ you (try to) communicate with it, the drive > will get stuck in an endless loop. You will have to reset it again and > be more patient this time. ;-) Thanks for this more detailed explanation. I mentioned the -03 and -01 ROMs as they need more time to start up in certain conditions (when the Autoboot-Code thinks it should boot something from the drive). > Spiro, contact me if you'd like to embed it into cbm4linux; I'll point > you to the respective code in the Commander source. Bye, Yes, I want to include it in cbm4linux/cbm4win. I already spoke with WoMo about this (*some* time ago). Anyway, until now, I totally forgot about that. Regards, Spiro. -- Spiro R. Trikaliotis http://www.trikaliotis.net/ http://cbm4win.sf.net/ |
|
From: Dirk J. <do...@cu...> - 2005-07-14 11:00:28
|
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 |
|
From: Spiro T. <tri...@gm...> - 2005-07-14 12:25:29
|
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/ |
|
From: Dirk J. <do...@cu...> - 2005-07-14 14:33:45
|
> One could come to the conclusion that these always changing APIs do no > good. It is the Linux' way to force people keeping up. You'd better ask this on LKML and be prepared for tons of flames :-) > 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. You're right at this point. I've now reworked all my changes and came up with 6 patches, which should do only one thing at a time, although some of them patch in the same areas and are therefore slightly dependand on each other. I have updated the patches on http://sourceforge.net/tracker/?group_id=45917&atid=444478 > 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. I have a machine which can boot linux 2.6 and XP. And I'm willing to help out. > 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 I don't insist on dropping support for old kernels if people want to keep it. I can live with the code present in the source, as it's #ifdef'ed anyway. -- ---> doj / cubic ----> http://cubic.org/~doj -----> http://llg.cubic.org |
|
From: Spiro T. <tri...@gm...> - 2005-07-14 17:46:10
|
Hello Dirk, * On Thu, Jul 14, 2005 at 04:33:36PM +0200 Dirk Jagdmann wrote: > >One could come to the conclusion that these always changing APIs do > >no good. It is the Linux' way to force people keeping up. > > You'd better ask this on LKML and be prepared for tons of flames :-) Yes, I know. I have had this discussion more than once. Nevertheless, this is something I almost hate about Linux. > You're right at this point. I've now reworked all my changes and came up > with 6 patches, which should do only one thing at a time, although some > of them patch in the same areas and are therefore slightly dependand on > each other. > I have updated the patches on > http://sourceforge.net/tracker/?group_id=45917&atid=444478 Ok, it is obvious that they have to depend upon each other. Nevertheless, with these patches, it is easier to patch by hand if one wants only one patch and it fails. I had a look at your patches: 1. The compilation bug for 2.6 (1238239): Does this mean that parport_find_number(lp) replaces the loop from before? Doesn't the new loop work at all, or is this just a shortcut? BTW: Why did you rearrange the for() loop into a while() loop? (just out of curiosity, not that it matters) 2. The reset patch: Your description tells us that < 0 is a "smart reset", while "== 0" performs no reset at all. Anyway, I cannot find a difference between these two. Is this "smart reset" what Joe proposed, thus, something to be added in the future, or what is this for? Anyway, I see you insist on your "no reset" default. Wouldn't it be better to use a "safe" setting, thus, perform a reset, and let it be disabled by knowledgeable people only? 3. I like the kernel source directory patch (1189489), although I have not tested it yet (but what should go wrong with this?). Please, don't understand me wrong: I do not have anything against people providing patches, especially if it is not even my own code but Michael's. ;) Au contraire, I'm very happy other people look into it. I only want to tell you what my point of view is - and I am hoping to convince you. It seems it worked, at least partially. > >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. > > I have a machine which can boot linux 2.6 and XP. And I'm willing to > help out. Well, but it is much easier doing development and being able to test it yourself instead of asking others to do it, isn't it? > I don't insist on dropping support for old kernels if people want to > keep it. I can live with the code present in the source, as it's > #ifdef'ed anyway. Ok, thank you. Regards, Spiro. -- Spiro R. Trikaliotis http://www.trikaliotis.net/ http://cbm4win.sf.net/ |
|
From: Dirk J. <do...@cu...> - 2005-07-14 18:21:26
|
Hello Spiro, > 1. The compilation bug for 2.6 (1238239): Does this mean that > parport_find_number(lp) replaces the loop from before? Doesn't the > new loop work at all, or is this just a shortcut? Linux 2.6 does not have the parport_enumerate() function. It was replaced by parport_find_number() which saves you from coding such a bogus loop. > BTW: Why did you rearrange the for() loop into a while() loop? (just > out of curiosity, not that it matters) Just personal taste. I don't like for() loops with an empty body. > 2. The reset patch: Your description tells us that < 0 is a "smart > reset", while "== 0" performs no reset at all. Anyway, I cannot find > a difference between these two. Is this "smart reset" what Joe > proposed, thus, something to be added in the future, or what is this > for? I just copied the description from the comments next to the "int reset" definition. I haven't checked if the comments make any sense. > Anyway, I see you insist on your "no reset" default. Wouldn't it be > better to use a "safe" setting, thus, perform a reset, and let it be > disabled by knowledgeable people only? You got that wrong. I changed the semantics of the reset variable from beeing a boolean to the actual number of seconds that should be spent waiting after reset. My patch does not alter the default of a 5 second wait, but now this time is configurable via the reset variable. -- ---> doj / cubic ----> http://cubic.org/~doj -----> http://llg.cubic.org |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X