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.