From: Spiro Trikaliotis (ml-cbmhackers_at_trikaliotis.net)
Date: 2007-09-22 13:52:56
Hello, I am taking the opportunity to answer three mails in one here, as they are all highly related, and I do not want to "fork" the thread: * On Thu, Sep 20, 2007 at 12:35:28PM +0200 Gábor Lénárt wrote: > On Thu, Sep 20, 2007 at 10:38:41AM +0300, Marko Mäkelä wrote: [...] > > While the user interfaces of the Linux kernel and the GNU libc have > > remained pretty compatible, the Linux kernel interfaces do change > > even between minor versions. That is why it would be best to have > > drivers inside the official Linux kernel tree. However, that could > > be hard nowadays for projects like OpenCBM, given that the kernel > > development is dominated by commercial companies. > > This is a common misunderstanding about the Linux kernel. [...] > Your comparsion of ABI compatibility between in Windows or Linux is wrong > however, because kernel module interface in only a linking process or > somewhat similar stuff, [...] I am sorry, but loading a driver into Windows is nothing more than a (dynamic) linking process, either. It is just that you are linking to something that is (almost) guaranteed to stay the same between versions on the Windows side. In contrast, on the Linux side, it is not only not stable between versions; it is *deliberately* changed between versions. > most of the "drivers"/"modules" are using deep > in-kernel stuffs, In Windows, you are using "deep in-kernel stuff", too. The only difference: MS is documenting what you are supposed to be using. Thus, as long as you stay with these, the driver is likely to be able to run with newer versiosn of the kernel, too. If course, this is unfortunate in many cases. The internal structures change, so, MS has to re-invent wrapper for wrapper over and over again. Anyhow, it works, and the user-experience is a good one. > You can blame Linux here - of course - that its goals are not the best. But > for its original goals it's not a fault at all but the desired behaviour! I am sorry, but this is ... - No, I do not want to start a flamewar. Nevertheless, what you are essentially saying is: "It's not a fault, it's a feature." Somewhere, deep in my memory, I have heard this argument before. In my view, it is more like "broken by design". Unfortunately, it is nothing that can be fixed easily, as it is *intentionally* "broken by design"! The argument that Linux is a monolithic kernel isn't an argument, either: The Windows NT system essentially is also a monolithic kernel. Here, we have no difference between both of them. The only difference I see: While MS *encourages* you to make your own drivers for our own hardware, the Linux guys mainly *discourage* you unless you are doing it exactly like THEY want you to do it. Thus, in order to support Linux, you have to follow their rules (or shut up.) * On Thu, Sep 20, 2007 at 04:26:50PM +0300 Marko Mäkelä wrote: > I am not suggesting that the Linux kernel should have a stable module > API or ABI. In fact, it would be exactly the opposite of what the Linux kernel developpers want. Remember, they are just arbitrarily changing the "interface" - yes, the module interface is an interface, regardless if Gabor or the Linux developers like it or not - to make it as hard as possible for developers to follow, unless they want to integrate their driver/module into the kernel. But: > I hope that I can be proven wrong about the difficulty of getting > additional drivers accepted to Linus' Linux kernel tree. Even if we were to integrate it (which would be very hard, because OpenCBM "does not play nice" in order to be able to hold the timing): Integrating a driver into the kernel tree is not a guarantee that it will be compatible with the kernel in the future: The kernel developers will just "orphan" it if they feel like it is too much work to maintain it, leaving it in a state that it will not compile anymore, or they will arbitrarily drop the module out of the kernel. They have done this in the past for more important drivers. Users (= "customers") are not happy with this. * On Thu, Sep 20, 2007 at 04:20:32PM +0200 Gábor Lénárt wrote: > Sorry, I don't know OpenCBM well, but it would be also interesting idea to > think about OpenCBM implementation, like device drivers in user space > (http://lwn.net/Articles/66829/). Tell me how you want to achieve a timing precision of 4 us in user-space, and we will speak of this again. Note that OpenCBM has two modes: One is using the original CBM IEC routines. In this mode, this timing precision is really necessary. Even the "listener-hold-off", where the computer (C64, PC) has approximately 100 us to respond, is not possible in user-mode, and it is even hard in kernel mode if you do not want to use busy-waiting while stopping multitasking for this time. OpenCBM implements this with the help of an interrupt (on Linux and Windows). That's the reason why an XE cable does not work, but you need the XM cable so that the "right" line can produce an interrupt. Nevertheless, even with the interrupt, neither Linux nor Windows can guarantee that we are able to respond quickly enough in 100 us here. In the "bit-banging" times, that is, when OpenCBM has to write bit-by-bit to the floppy (or read the bits from it), OpenCBM even has to disable multitasking for the duration of every single byte! If this is not done, the communication is not reliable. The second mode of OpenCBM are the fastloader implementations of cbmcopy and d64copy, the serial1, serial2, and parallel protocol. With these, timing is not critical anymore. In fact, with these protocols, the OpenCBM driver is only responsible for communcation with the hardware itself, as direct I/O is not possible on neither Linux nor on Windows. Unfortunately, in order to establish the fast protocols, we have to use the IEC protocol to download the fast protocols onto the floppies. Note that there is essentially a third mode: There is special mnib support in OpenCBM. Here, the OpenCBM kernel part reads in a complete track from the floppy (approx. 8 KB) with stopped multitasking, or writes a complete track to the floppy - again, with multitasking disabled. We would never be able to get the complete track in user space. > It's the same idea as FUSE (filesystem in > user space). Sure, because of direct hw access, some kernel part may be > needed. This is about the idea that not everything should be placed in > kernel space, some things would fit better into userspace (just think about > special filesystems like sshfs and gmailfs: without FUSE they would be > almost impossible to do in kernel space). This is true; in fact, it is EXACTLY the approach OpenCBM uses: Only the parts absolutely necessary are in the kernel space. Note that another option would be to use some RT extensions for Linux. Nevertheless, the "RT extensions" all people are speaking off nowadays are far from being able to achieve that precision needed for OpenCBM. It would be possible to use RTAI or RT-Linux for this task, but both of them themselves have the same problem with the Linux kernel as the OpenCBM module itself has. Thus, we would not gain very much, but we would give up more control and give it to other companies (for example, FSMLabs). We would depend on them fixing the issues, instead of being able to fix them ourselves. Regards, Spiro. -- Spiro R. Trikaliotis http://opencbm.sf.net/ http://www.trikaliotis.net/ http://www.viceteam.org/ Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.