Re: compiling opencbm under Ubuntu

From: Spiro Trikaliotis (ml-cbmhackers_at_trikaliotis.net)
Date: 2007-09-30 19:25:16

Hello,

oh, well, I believe this is OT, nevertheless, I cannot refuse to answer.

* On Wed, Sep 26, 2007 at 01:57:01PM +0200 Gábor Lénárt wrote:
 
> On Sat, Sep 22, 2007 at 01:52:56PM +0200, Spiro Trikaliotis wrote:
 
> For being short (because it's declared Off-topic here), the problem: Windows
> has got some abstraction layer which is designed to be quite constant in
> time (well at least in short time range I guess ...),

What is "short time range" in your view? Most parts of the driver API
have been stable since NT 3.1 (1993). Yes, there have been extensions,
but that's most of it.

Of course, there are some changes. The only "big one" many people would
recognize is the graphics driver API: In Windows NT 3.1, 3.5 and 3.51,
graphics drivers were userspace-DLLs. This changes with NT 4, where the
graphics cards went into the kernel-mode.

> I mean: in case of Linux the whole goal of "modules" was not designed
> as 3rd party driver interface (it's another question that nowdays it's
> being used for that purpose by some vendors with more or less success)
> but for the ability not to compile in all the drivers into the kernel
> (statically) for a distribution.

Ok. So, we have to be thankful that we are allowed to use the kernel for
our own projects, building our own "drivers". Is this what you want to
say to me?

>  
> > In my view, it is more like "broken by design". Unfortunately, it is
> 
> It depends on your mood. For example I can treat closed source as "broken by
> design", and in this case, I don't want anything linking against az open
> source stuff through an abstraction layer which makes easier to "infect" an
> open source project with closed source blobs (even now Linux kernel
> developers refuses debug problems if kernel is 'tainted' since there is no
> way to debug the effect of a closed source module to the system.

No, there is "no way to debug the effect of a closed source module to
the system"? Then I am doing something impossible when I try to debug
problems on Windows machines without having code? Interestingly.

Regardless on your point of view of closed source software, playing
cat-n-mice with ANY software driver developer for any hardware is not
the best way to treat your users, is it?


> however even Microsoft often blames 3rd drivers for Windows stability
> problems,

Yes: In fact, they are right in many circumstances.

I developed my first driver for Windows NT 4.0. Well, to be more
precise, I got the sources for a commercially available driver and I had
to modify it in order to implement an additional functionality into it.
As I wanted the driver to be as stable as possible, I used everything I
could get to make it work.  Thus, after the driver worked as expected, I
installed the "checked build" of NT4. That "checked build" is just a
debug build, with many tests for the driver behaving as it should.

(Yes, I know: The checked build would have been better during
development. Unfortunately, although the company I worked for had an
opportunity to get the checked build, I had to CONVINCE the people to
give me that build. And it took me very much time to convincen them...)

Guess what? I was not able to boot the system with the checked build.
The graphics' driver was broken, the network drivers were broken, and so
on. I stopped investigating after I found this out, especially since I
found out that the driver I was modifying NEVER would "survive" the
checked build of NT4.

MS started signing the drivers (WHQL). Although I did not like this -
especially since I would never get OpenCBM WHQLed, as I *have* to do
some dirty tricks to hold the timing -, I could clearly understand MS.
They had to do it to defend their system.


> they use some validation process now to call a driver 'stable' - sorry
> I don't know the exact name for this notion -, unfortunately it's
> cannot be done with Linux easily because vendors of closed source
> drivers won't give source to Linux developers without an NDA or such,

Why do the Linux developers need sources? Almost (*) every driver can be
WHQLed without sources. WHQL performs some tests on the binary driver,
not on the sources.

(*) IIRC, there are some types of drivers MS did not sign until they had
access to the sources. IIRC, this is not true anymore now.


> So nowdays kernel developers are in strange situation that they cannot
> debug problems of their users because of closed source blobs injected
> in their system whose effect to the whole kernel is highly unknown for
> them).

I have a good idea: Make stable APIs, so others can build drivers
without having to follow every single change. Then, make tools that are
able to *test* these stable APIs. ("Driver Verifier" is one such tool,
and it is very good, getting better and better with every version of
Windows). Oh, and don't let every other driver use arbitrary parts of
the OS.

This helps a lot against this. ;)

 
> Just wanted to show that this problem is not caused because ugly and
> evil Linux kernel developers don't want 3rd modules _at_ _all_, but
> because of other facts too (and mainly).

What are these other facts? Is it the fact the Linux does not even try
to implement the slightest form of protection against its drivers, so
people are not able to debug problems anymore? BTW: A good debugger
helps, too. WinDBG (which can be used for kernel debugging) is a good
tool in general.

> > 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.)
> 
> As with windows. Eg you must sign NDA to see some source/spec, etc.

You don't need to always see the source in order to use something. While
I like open source, and I would like to see Windows open-sourced,
open-source also has a big drawback: Instead of looking at the
specification, people often tend to only look at the implementation:
"Oh, it is implemented this way? Fine, so I can use this-or-that
shortcut." It's a pity that this shortcut will crash the whole system in
the next version, as the implementation has changed, isn't it?

The difference here between MS and Linux developers: MS at least *tries*
to minimize these effects. Yes, Microsoft even tries to circumvent
errors in user mode applications. Why? Because if an broken application
does not work any longer with a new version of Windows (but it seemed to
work on an older version of it), people blame Microsoft, not the company
who wrote the broken code. Yes, this is something I find crazy, to
program around the bugs of other programs. The OS has special code to
treat many applications specially. This is also true for drivers.

I am sure you know how Linux handles this, in contrast. Yes, Linux
people might be right to blame the application programmer for a bug.
Unfortunately, these problems also occur because the documentation
is - well, sort of "lacking" in many cases. In some cases, the source is
the *only* 'documentation' available!

 
> Also, you can read file "stable_api_nonsense.txt" from the kernel source
> tarball (from directory Documentation).

No, thank you, I have already read that nonsense more than once... Yes,
I have also read the nonsense about why Linus does not want a kernel
debugger...

 
> For OpenCBM it's really a hard question, it's true. Because it's a quite
> special driver which is needed for only a few people (well, compared to the
> number of all Linux users, I mean), and it's harder to be the part of Linus'
> source tree for a driver which is so special.

This is exactly the point.


> > Tell me how you want to achieve a timing precision of 4 us in
> > user-space, and we will speak of this again.
> 
> Don't know, that's why I used conditional mode in my sentence :) Sure an
> external uC would solve the problem but than it would be an extra hardware
> as a requirement so it's not the best solution for all.
[...]
> Maybe it's worth to use extra external hardware after all? If it's cheap
> enough (and eg using USB as hw interface towards the PC, it would be
> comfortable: modern PCs start loosing 'legacy' ports, it seems) it would be
> suitable, eg it would handle most of the timing problems, and maybe it's
> easier to implement a driver for the OS itself, as well because of the
> external hw "help" from the uC. Maybe, even a "driver in user space" would
> be enough?

<coming-back-to-topicality>

That's why we are working on the xu1541. In fact, Till (who made the
hardware and most of the software) was tired of having to compile the
OpenCBM module over and over again, because he just upgraded his kernel.
:(

With xu1541 support, no kernel-mode driver is needed anymore. The xu1541
used an Atmel AVR with a software USB stack. Unfortunately, the xu1541
is *slower* than the XM/XA1541, especially with a parallel cable. :(

</coming-back-to-topicality>

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.