lkml.org 
[lkml]   [1999]   [Dec]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectLimited Exposure Required!! (Re: Portable binary drivers)

Mr. Kendall Bennett,

If you are serious about the issue, put up or shutup!!!
I am here to put it (CLAPI) up on the table my model.
Since I need a strong test model/case, what does "SciTech Software Inc"
have in a driver form that is considered IP that could never be released?

CLAPI, trying to put it into words for the masses of normal thinkers.

On Mon, 6 Dec 1999, Ingo Molnar wrote:

>
> On Sun, 5 Dec 1999, Kendall Bennett wrote:
>
> > Binary portable modules != close source proprietry drivers
>
> > I would rather see vendors release Open Source device drivers because
> > they understand these benefits, than because they are forced to do so.

In order the above to happen you have to give them something to think
about. I spent more than an hour at Comdex with an unamed company
explaining linux kernel development, GPL, LGPL, and CLAPI.

This (may be|was) the first test case for an API of this design.

The results are out of pocket as of now; however, understand that
being able to get a company to re-think that which is defined as IP, and
seeing that their scope of coverage is out of balance with reality, is
a major step in the desired endpoint. Once we get to this point, the
boundary of disclosing the hardware API level to GPL is basically a done
deal. (see below, for why)

> why is it impossible to keep the module API constant? Because Linux
> evolves so fast, and the goal of Linux is to integrate drivers into the OS
> as much as possible. This is a constantly fluctuating process, APIs,
> constants and frameworks change frequently (and without us knowing about
> it advance). This is essential to Linux, it gives us speed and generic
> drivers. i386 networking drivers worked almost out of box on other

Ingo's point here is a FACT of LINUX......

> sadly it's not possible to distinct between 'good' binary modules (which
> are open-source), and 'bad' binary modules (which are closed-source) - but
> this is not a problem! i'm sure you will understand the point: it's not
> hard to create a 'module compilation package' that compiles the binary
> module on the spot. We _do_ guarantee driver source-compatibility for the
> stable branch. An on-the-spot driver compilation framework would be a
> welcome addition to Linux (feel free to contribute it), as it can eg.
> optimize for the given CPU and architecture.

Ingo,

Will you back up just a faction of a cycle and let me insert a thought?

Is it not only 5% of the process of driver development figuring out what
and where the address are to do the first initialization and load?
We all know that this is second worst part of the nightmare of driver
development, IMHO....

The next 10% of the time is setting up the handlers or callbacks, IMHO....

<MOT> "mildly OT"
I find no reason to have raised the spector of this issue to the degree
that it is now, by "SciTech Software, Inc". I had planned to announce
"CLAPI" after I had a strong case with super-cool additions to Linux.

The "binary drivers" issue needed a cold shower!!!!!
</MOT>

We all can get to this point regardless if the vendor is helpful or not,
and beyond this threshold is the point of true grit and desire.
I claim that this is the point of no return for vendors that do not
understand the mindset.....The, "I have a secret" children's game. YES, I
am currently playing that game with "CLAPI", but it is necessary until I
can brief Linus in person and show him the results. And we begin.....

<the cc list just bloomed......apology issued here after the fact>

************

The next 65% of the time is spent on constructing the usage of the stuff
above, IMHO....or consider kernel callouts via a devfs point to do this
for us.

So, we now can register a new piece of hardware, from a vendor who is
afraid of GPL....but he can be safe with LGPL.

How do we offer an olive branch of faith with LGPL and not VIOLATE the
kernel's openness?? It is obvious that NO ONE is to ever conside the case
of linking a library to the kernel, I never considered this NOP.

First the vendor is REQUIRED to provide Linux with a basic core driver for
registering the device and to hold the configuration key to allow
communication to the outside world via "fops" or a derivative to build in
limited OEM driver support (functionless, but accessable).
This first point is contingent on a LGPL library with "ALL" the OEM
driver support callouts. It would be desirable for this to be strong
enough to provide limited support, but not require at this point.

<MAJOR ISSUE & RANT>
If the vendor will not do this much, LATER.............
I have no time to put diapers on the minds of infants!!!!!
</MAJOR ISSUE & RANT>

Second, one sets a compile flag for CONFIG_CLAPI.

Third, one sets the driver specific flag to grant needed driver access.
This is a custom kernel build option and should never be in a stock
off the shelf distribution, except for VAR support secondary kernel
install support.

Fourth (Richard, you are going to love this one) "devfs" is required,
for CLAPI will most likely require or employ something in this field.

What do we have now?????

A kernel with limited OEM driver support (functionless, but accessable).
[kernel(driver->fops->clapi)]
A cool LGPL library with "ALL" the OEM driver support callouts, provided
and maintained by the vendor....not kernel people, unless a timelimited
GPL signed legal dead date is binding (major sticking point).
[library(<sys/ioctl.h>, standard control calls)]

What do we need????

A secure daemon-like binary (source preferred) for now, to become the
software engin of the driver built-in. This will be provided by the OEM
or if generic in form and reaction because of the next generation of CLAPI.

This tool is required to be bi-directional, multi-piped, or
multi-threaded. Only this design, at this time, could provide the means
to respond to driver request to the library and return the results.

Performance PRICE????

INVERSELY proportional to how much the internal drive can handle and how
much it has to depend on assistance.

UP v/s SMP issue????

Minor or NONE, dependent on the above if at all......

Security issue????

FOOLS trust MiniPort(tm), they should have no fear of CLAPI!!!

*********

Seriously, here is the point of concern for all.
Since we are not currently restricting the read/write of blocked
user-space memory into the kernel for use, could a nasty arise for
a daemon-like tool performing such a task........if we are careless
yes, just like being careless with network security will bite you one day.

Well there are many more nights of this to be addressed.

If this is totally not doable in the kernel with the requirements of
the most basic OEM support, IMHO, I will continue to try and answer the
other question of "What happened between time 0 and 10e-37 seconds after
the BigBang?"............that is for you Alan.......

It will be this friday or the beginning of next week before I will
followup. I have to help the guys who got and proved the first optical
data of a planet transit about another star, follow the BBC for more
details or <http://schwab.tsuniv.edu/t8/hd209458/transit.html>.

Andre Hedrick
The Linux IDE guy
-----------------------------------------------------------------
SuSE Inc. - Makers of SuSE Linux
Andre Hedrick, 580 2nd Street, Ste 210, Oakland, CA 94607 USA
PH: 510-628-3380 FAX: 510-628-3381 www.suse.com
-----------------------------------------------------------------


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.218 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site