Driver HOWTO ?
Armin Steinhoff
Hello,
are there any information/HOWTOs about writing of drivers for Minix 3.0
available ??
Regards
--Armin
Megab...@gmail.com
I may start writing one as soon as I finish reading through the drivers
that are included. I think I have a general idea of how they work, but
not quite enough to write a HOWTO or even a driver. Gimme a week or so
and I should have something done.
Armin Steinhoff
OK ... it was just a question. I will at next install and read the
sources. Hope the drivers are well commented ??
--Armin
Segin
Armin Steinhoff wrote:
--
I still maintain the point that designing a monolithic kernel in 1991 is a
fundamental error. Be thankful you are not my student. You would not get a
high grade for such a design :-)
(Andrew Tanenbaum to Linus Torvalds)
Megab...@gmail.com
don't explain everything...
Armin Steinhoff
> Are you kidding? they are well commented, just like my code.
Segin wrote:
"And I know virtually nothingabout PROGRAMMING a driver (i understand
the concepts quite well however, and wrote a thesis paper for no
particular reason, even though i might want to wait until I am out of
high school)"
Are you kidding???
--Armin
Segin
I write various libraries and applications, of which are loaded with
comments. I did take a peek at the Minix drivers, and they too are loaded
with comments.
So we both have a foot in our respective mouths.
Armin Steinhoff wrote:
--
Intel engineering seem to have misheard Intel marketing strategy. The phrase
was "Divide and conquer" not "Divide and cock up"
(By iia...@www.linux.org.uk, Alan Cox)
d
Armin Steinhoff
> I didn't say I coded drivers, now did I?
>
> I write various libraries and applications, of which are loaded with
> comments. I did take a peek at the Minix drivers, and they too are loaded
> with comments.
>
Coding stile and commented code can't show ALL features of the driver
modell!
AFAIS ... it should be very easy to port our QNX4 based fieldbus drivers
to Minix 3 :)
--Armin
http://www.steinhoff-automation.com
Segin
> Coding stile and commented code can't show ALL features of the driver
> modell!
I'll give you that, as I still can't write a Linux driver for shit even
after reading (virtually) every driver in the kernel.
> AFAIS ... it should be very easy to port our QNX4 based fieldbus drivers
> to Minix 3 :)
I have no idea what a fieldbus driver is, but I know what QNX4 is...
Is this driver of yours comercially developed? And if so, will the Minix
version be under a OSI-approved license? (OSI web site:
http://www.opensource.org)
> --Armin
--Segin
> http://www.steinhoff-automation.com
http://segin.no-ip.org (My be down for any number of idiotic reasons)
jfat...@aol.com
> AFAIS ... it should be very easy to port our QNX4 based
> fieldbus drivers to Minix 3 :)
My enthusiasm for Minix 3 derives from my own QNX 4 (POSIX microkernel)
experience several years ago. Minix 3 will need to catch on and
develop a user community beyond the classroom to approach QNX in
utility, but if it does, it could become a really compelling
alternative.
Please note that I have no dispute with QNX. They make a very fine
operating system and I enjoyed using it. I just want an open source
alternative so I can master the internals (the technical appeal), and
avoid licensing fees (the commercial appeal).
Segin wrote:
> Is this driver of yours comercially developed? And if so,
> will the Minix version be under a OSI-approved license?
Since Minix 3 is released under a BSD style license, there is no
requirement that Armin's driver be released under an OSI approved
license. This is the chief non-technical appeal of Minix 3.
If someone develops generally useful code that runs under Minix 3, they
should contribute that back to the community since they benefit from
the generous contributions of others. But if their value add targets a
very narrow market where their source would only be of value to their
direct commercial competitors, they should be free to hold that source
closed.
Viral licensing such as the GPL is often a problem for commercial
developers in niche markets who would otherwise like to develop for
Linux. It is great that Minix 3 went with a BSD style license to avoid
this problem.
The ability to hold source closed where warranted should encourage
Minix 3 adoption, so users who select this path should be respected.
They contribute in a useful, albeit less direct, manner.
Thanks.
Jim
Armin Steinhoff
> Armin Steinhoff wrote:
>
>
>>AFAIS ... it should be very easy to port our QNX4 based
>>fieldbus drivers to Minix 3 :)
>
>
> My enthusiasm for Minix 3 derives from my own QNX 4 (POSIX microkernel)
> experience several years ago. Minix 3 will need to catch on and
> develop a user community beyond the classroom to approach QNX in
> utility, but if it does, it could become a really compelling
> alternative.
It depends on your requirements. If you don't need real-time and
threads, but a robust and secure micro kernel running on a single
CPU ... Minix 3.0 could be an alternative.
However ... Minix 3.0 is new and QNX is now ~20 years in the RTOS
market, so you have to be realistic :)
> Please note that I have no dispute with QNX. They make a very fine
> operating system and I enjoyed using it. I just want an open source
> alternative so I can master the internals (the technical appeal), and
> avoid licensing fees (the commercial appeal).
>
> Segin wrote:
>
>
>>Is this driver of yours comercially developed? And if so,
>>will the Minix version be under a OSI-approved license?
>
>
> Since Minix 3 is released under a BSD style license, there is no
> requirement that Armin's driver be released under an OSI approved
> license. This is the chief non-technical appeal of Minix 3.
>
> If someone develops generally useful code that runs under Minix 3, they
> should contribute that back to the community since they benefit from
> the generous contributions of others. But if their value add targets a
> very narrow market where their source would only be of value to their
> direct commercial competitors, they should be free to hold that source
> closed.
>
> Viral licensing such as the GPL is often a problem for commercial
> developers in niche markets who would otherwise like to develop for
> Linux. It is great that Minix 3 went with a BSD style license to avoid
> this problem.
Drivers for Minix 3.0 are not kernel modules ... so 'tainted drivers' is
not an issue for Minix 3.0. It is a real big problem with LINUX 2.x ...
as the recent discussion about a kernel driver API for LINUX shows.
LINUX is on the way to loose support for high tech hardware ... graphic
controller a.s.o.
> The ability to hold source closed where warranted should encourage
> Minix 3 adoption, so users who select this path should be respected.
> They contribute in a useful, albeit less direct, manner.
Yes ... the contribution could be to open the doors for new areas of
applications of Minix 3.0.
Regards
--Armin
>
> Thanks.
>
> Jim
>
James Buchanan
> If someone develops generally useful code that runs under Minix 3, they
> should contribute that back to the community since they benefit from
> the generous contributions of others. But if their value add targets a
> very narrow market where their source would only be of value to their
> direct commercial competitors, they should be free to hold that source
> closed.
Why should commercial entities be exempt from giving back to the
community? There is no justification but paranoia to keep sources closed
when they are built on the back of other peoples' sweat.
> Viral licensing such as the GPL is often a problem for commercial
> developers in niche markets who would otherwise like to develop for
> Linux. It is great that Minix 3 went with a BSD style license to avoid
> this problem.
GPL licencing is actually a help to developers, especially if they are
contributing to something which may take off as a commercial venture. If
they get sloppy and start licencing under BSD, then a company can come
along and take their work, essentially hijacking it.
If anyone creates a new port of Minix 3 or makes it more useful or
stable, please consider keeping it in the hands of the community by
licencing under the GPL. Using the BSD licence leaves your work open to
being made closed source.
> The ability to hold source closed where warranted should encourage
> Minix 3 adoption, so users who select this path should be respected.
> They contribute in a useful, albeit less direct, manner.
I seriously doubt there are any situations where keeping sources closed
is warranted. The only thing keeping Minix back from adoption is
marketing and spin.
I have no respect for users who take the efforts of others and keep
their own stuff closed. They should not be respected, and discouraged.
When they build a Minix-like system from scratch themselves is the day
I respect their choice of closed source.
Keeping useful additions or improvements closed source smacks of
arrogance and selfishness.
Philip Homburg
James Buchanan <ask...@no-spam-thanks.com> wrote:
>jfat...@aol.com wrote:
>> If someone develops generally useful code that runs under Minix 3, they
>> should contribute that back to the community since they benefit from
>> the generous contributions of others. But if their value add targets a
>> very narrow market where their source would only be of value to their
>> direct commercial competitors, they should be free to hold that source
>> closed.
>
>Why should commercial entities be exempt from giving back to the
>community? There is no justification but paranoia to keep sources closed
>when they are built on the back of other peoples' sweat.
I think the point of the BSD-style licenses is that the code is gift to
the world. When you give something to other people you don't add a list of
conditions on how they have to use it.
>> Viral licensing such as the GPL is often a problem for commercial
>> developers in niche markets who would otherwise like to develop for
>> Linux. It is great that Minix 3 went with a BSD style license to avoid
>> this problem.
>
>GPL licencing is actually a help to developers, especially if they are
>contributing to something which may take off as a commercial venture.
The GPL has a different goal.
In the end it is the author who decides which license is best.
>If
>they get sloppy and start licencing under BSD, then a company can come
>along and take their work, essentially hijacking it.
There is no 'hijacking'. The community can keep the original code alive
even if there are competing products (based on that code) from companies.
A lot of companies benefit from research done at universities. They don't
have to give anything back. Software under a BSD-style license is similar
to that.
If a company builds a product on top of Minix instead of, say, Windows and the
end result is more stable, or is cheaper then that is a net benefit to
society as a whole. Even if the use of Minix only make the share holders
richer, the Minix community doesn't really lose anything.
--
That was it. Done. The faulty Monk was turned out into the desert where it
could believe what it liked, including the idea that it had been hard done
by. It was allowed to keep its horse, since horses were so cheap to make.
-- Douglas Adams in Dirk Gently's Holistic Detective Agency
Armin Steinhoff
> jfat...@aol.com wrote:
>
>> If someone develops generally useful code that runs under Minix 3, they
>> should contribute that back to the community since they benefit from
>> the generous contributions of others. But if their value add targets a
>> very narrow market where their source would only be of value to their
>> direct commercial competitors, they should be free to hold that source
>> closed.
>
>
> Why should commercial entities be exempt from giving back to the
> community?
What should they give BACK to the community? As specially when their
application software doesn't re-use or integrate the sources of the OS??
> There is no justification but paranoia to keep sources closed
> when they are built on the back of other peoples' sweat.
It is often 'paranoia' based on non-disclosure contracts ....
>
>> Viral licensing such as the GPL is often a problem for commercial
>> developers in niche markets who would otherwise like to develop for
>> Linux. It is great that Minix 3 went with a BSD style license to avoid
>> this problem.
>
>
> GPL licencing is actually a help to developers, especially if they are
> contributing to something which may take off as a commercial venture.
No, the GPL doesn't help the developers ... it helps just the
'distributors' of their work :)
>If
> they get sloppy and start licencing under BSD, then a company can come
> along and take their work, essentially hijacking it.
>
> If anyone creates a new port of Minix 3 or makes it more useful or
> stable, please consider keeping it in the hands of the community by
> licencing under the GPL. Using the BSD licence leaves your work open to
> being made closed source.
>
>> The ability to hold source closed where warranted should encourage
>> Minix 3 adoption, so users who select this path should be respected.
>> They contribute in a useful, albeit less direct, manner.
>
>
> I seriously doubt there are any situations where keeping sources closed
> is warranted. The only thing keeping Minix back from adoption is
> marketing and spin.
>
> I have no respect for users who take the efforts of others and keep
> their own stuff closed. They should not be respected, and discouraged.
> When they build a Minix-like system from scratch themselves is the day
> I respect their choice of closed source.
This approach is very OS centric ... the technology of application
software is often also be very challenging and KNOWHOW driven.
>
> Keeping useful additions or improvements closed source smacks of
> arrogance and selfishness.
This view has nothing to do with the reality of software developers who
have to earn their money by their WORK!
--Armin
David Given
Hash: SHA1
In article <437171a8$0$14240$5a62...@per-qv1-newsreader-01.iinet.net.au>,
James Buchanan <ask...@no-spam-thanks.com> writes:
[...]
> GPL licencing is actually a help to developers, especially if they are
> contributing to something which may take off as a commercial venture. If
> they get sloppy and start licencing under BSD, then a company can come
> along and take their work, essentially hijacking it.
OTOH this does mean that if a company can't or won't release sources or
information for a piece of hardware, then that piece of hardware *never
does* get supported, which means that everybody loses out. The days when
hardware could be easily reverse engineered are pretty much over. These
days, to pick an example, your average wireless card is a fully-fledged
microcontroller with its own RAM and operating system. In order to do
anything at all with it, you've got to upload a (copyrighted) firmware
blob.
[...]
> Keeping useful additions or improvements closed source smacks of
> arrogance and selfishness.
Not necessarily.
The company I work for produces an embedded operating system, intent. In
the past, we produced a *different* operating system, Taos. Taos was
obsoleted by intent but still has a number of nice features. I suggested
that it might be nice to open source this as a good-will gesture, and to
increase mind-share and company awareness.
Simply not going to happen. The reason is that it would take huge amounts
of work to simply verify that *we* own sole rights to everything in the
codebase (because there might be third-party licensed code in there). The
legal issues are huge, and require *effort* to sort out. Given that we make
no money from Taos and it's unlikely we ever well, it's simply not
cost-effective.
The same applies to any other company. If you're a hardware company, and
you write a driver, it's easy to release binaries. It's *much harder* to
release source. Not only do you need to sort out the legal issues, but
you've also got to pore through all the code to make sure that you're not
giving away any information you're not supposed to be giving away... plus,
of course, you have to have teams of people examine every line for comments
such as "/* Kludge to work around [vendor names] brain dead hardware design
*/". Then you end up having to deal with support issues when you're
releasing one version of a driver, but half your prospective customers are
using a patched driver released by some random third party who never
bothered to tell you that they were doing that... it's a support nightmare.
Of course, it would be nice if the hardware vendors released open source
vendors, and I have a lot of respect for those who do. But it's *hard*.
Really hard. Given that these are hardware companies, not software
companies, they may not be able to afford it. Saying it's simply arrogance
and selfishness is an oversimplification.
- --
+- David Given --McQ-+
| d...@cowlark.com | "The further you are from your server, the more
| (d...@tao-group.com) | likely it is to crash." --- Woodhead's law
+- www.cowlark.com --+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDceGRf9E0noFvlzgRAnGWAKChts6+tYdjaoxJjTJS5kE1m035LACg1QAh
7QPWtqTayiC/uWe8blkQcFs=
=Etx2
-----END PGP SIGNATURE-----
jfat...@aol.com
> Saying it's simply arrogance and selfishness is an
> oversimplification.
I agree. As an example, I recently needed to add an AVL tree to an
embedded telephony product. I looked at GNU libavl first. It did just
what I wanted, but the viral GPL licensing would have required that we
open source our proprietary embedded software.
Please note that our modifications to the library were only to adapt it
at the integration level to our product. We did not make any
algorithmic or feature changes that would be of any interest to other
AVL tree users.
But since GNU libavl was released under the GPL, we had to keep
looking. I ended up using the libdict library, which also provided the
necessary AVL tree support, but under a BSD style license. So we could
adapt the source in ways that were useful to us but of no interest to
any other libdict users.
I don't think this approach violates the spirit of open source. And we
were happy to adhere to the letter of the BSD license and include
Farooq Mela's (the libdict author's) copyright notice. We respect and
appreciate his contribution.
I remember when Linux really got going in the mid-90's. There was a
lot of debate regarding the responsibilities of commercial vendors to
contribute source. Some did, some didn't. The LGPL and implementation
of drivers as loadable modules provided an escape for driver writers
who didn't need to make changes to the kernel proper. Some approved of
that exception, some didn't.
I remember that a *lot* of commercial ventures sprung up, with
substantial financial backing, to exploit Linux. Most have faded away,
but some still remain. IBM's commitment was questioned, but they have
continued to heavily promote Linux. Linux benefitted enormously,
without any capital investment by the open source community in
marketing. Everybody won.
The point is that commercial interest with regard to open source is not
by definition bad. It was a real help getting Linux out from under the
desk and into the server room, and into embedded devices. And now,
there are hundreds of manufacturers (who have to turn a profit every
quarter and pay their Linux software engineers) who have embraced
Linux. Other companies have been formed based on a business model
centered on catering to the embedded Linux market.
If you want Minix 3 to become a broad success, then I think it is valid
to wish for substantial commercial interest and success exploiting it
in creative ways that add value.
BTW, my interest in Minix 3 is technical, not commercial. My perhaps
unfortunate pattern of behavior is to remain head-down banging out code
for the joy of it, while the other guy gets rich.
Thanks.
Jim
Martijn van Buul
> There is no justification but paranoia to keep sources closed
You obviously never worked for a software company.
--
Martijn van Buul - pi...@dohd.org - http://www.stack.nl/~martijnb/
Geek code: G-- - Visit OuterSpace: mud.stack.nl 3333
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not 'Eureka!' (I found it!) but 'That's funny ...' Isaac Asimov
James Buchanan
> You obviously never worked for a software company.
I've worked for several and even have my own.
James Buchanan
> Of course, it would be nice if the hardware vendors released open source
> vendors, and I have a lot of respect for those who do. But it's *hard*.
> Really hard. Given that these are hardware companies, not software
> companies, they may not be able to afford it. Saying it's simply arrogance
> and selfishness is an oversimplification.
I couldn't care less about their copyrighted firmware, their stupid
legal hassles, or their IP or whatever. This kind of what's your's is
mine and what's mine is mine attitude is a disgrace, and it's harmful to
our society generally, not to mention the PC industry and everything it
touches.
James Buchanan
> I think the point of the BSD-style licenses is that the code is gift to
> the world. When you give something to other people you don't add a list of
> conditions on how they have to use it.
There are no conditions on how they have to use it. There are no
conditions that they must share profits from sales. There are no
restrictions other than that you share and share alike. When given
source, improve, and give source back. It's that simple. But I suppose
the pointy-haired boss' little head would explode.
> There is no 'hijacking'. The community can keep the original code alive
> even if there are competing products (based on that code) from companies.
So...?
> A lot of companies benefit from research done at universities. They don't
> have to give anything back. Software under a BSD-style license is similar
> to that.
Who cares if they benefit from research done at universities. I'm not
talking about the benefits to companies. I couldn't care less about
psychopathic institutions like for-profit corporations.
> If a company builds a product on top of Minix instead of, say, Windows and the
> end result is more stable, or is cheaper then that is a net benefit to
> society as a whole. Even if the use of Minix only make the share holders
> richer, the Minix community doesn't really lose anything.
I agree that it would be better for society as a whole to have something
other than Windows running in embedded devices or whatever. But the
whole point is, why compromise and allow them to take and not share back
their changes/improvements just so corporations can benefit? How about
promoting sharing and helping each other out over and above giving in to
corporations for a change?
Philip Homburg
James Buchanan <ask...@nospam-thanks.com.au> wrote:
>Philip Homburg wrote:
>> I think the point of the BSD-style licenses is that the code is gift to
>> the world. When you give something to other people you don't add a list of
>> conditions on how they have to use it.
>
>There are no
What are you trying to say here? 'There are no restrictions other than'
basically means 'there are some restrictions'. To me using open source includes
releasing modified versions. And the GPL does impose restrictions on the
way programs are released.
You may think that those restriction are a minor issue. However that is
upto the receiver to determine.
>But the
>whole point is, why compromise and allow them to take and not share back
>their changes/improvements just so corporations can benefit? How about
>promoting sharing and helping each other out over and above giving in to
>corporations for a change?
Because in the BSD model sharing is voluntary. If somebody wants to share,
that is fine. If somebody just wants to take, then it is his (long term)
loss.
Note that the GPL doesn't come for free. There is reason to believe that gcc
is structured in certains ways to avoid 'circumvention' of the GPL.
But in the end, it is the authors' to decide. If you contribute code to Minix,
you can release it under the GPL.
(Of course, you can also create you own fork: GPL-Minix, or GNU/Minix, or
whatever).
Armin Steinhoff
> Philip Homburg wrote:
>
>> I think the point of the BSD-style licenses is that the code is gift to
>> the world. When you give something to other people you don't add a
>> list of
>> conditions on how they have to use it.
>
>
> There are no conditions on how they have to use it. There are no
> conditions that they must share profits from sales. There are no
> restrictions other than that you share and share alike. When given
> source, improve, and give source back. It's that simple.
That's just one of these simple GPL illusions. Who is really able to
change the kernel of LINUX ... or can change other deeply to hardware
related software?.
You need not only the sources ... you need detailed information about
hardware interfaces and technological know how in order to handle it.
Without it ... sources are useless!
--Armin
se...@segin.no-ip.org
On Fri, 11 Nov 2005, James Buchanan wrote:
>
> I couldn't care less about their copyrighted firmware, their stupid legal
> hassles, or their IP or whatever. This kind of what's your's is mine and
> what's mine is mine attitude is a disgrace, and it's harmful to our society
> generally, not to mention the PC industry and everything it touches.
>
And what does this have to do with anything?
But yeah, you do have a point.
Kelly Hall
> That's just one of these simple GPL illusions. Who is really able to
> change the kernel of LINUX ... or can change other deeply to hardware
> related software?.
My experience is different. My employer just completed an 8 month
project with 5 developers where we've essentially written a new TCP/IP
stack and added it to the FreeBSD kernel. The features of the new stack
are very useful for our business needs; useful enough that it made sense
to spend significant resources on this task for the competitive
advantage it gives us.
If we were using Linux, this sort of project wouldn't have been started
since we'd be obligated to make the source public, giving away our
advantage. Which is why we use FreeBSD in the first place...
Kelly