I have to agree here, one of the major issues in writing device drivers,
which I used to do for a living, is getting proper documentation for
the devices themselves. For something like video cards, it's even worse
because the cards change so rapidly. I can imagine that there will be some
On Mon, 24 Jan 2000, William A. Maniatty wrote:
I'm probably not quite cool enough to be in on the joke here, but what
is a dog polisher?
You use it to polish your dog.
Since all good dog polishers connect to computers running unix, you need a
device driver to interface with the dog polisher.
-On [2124 10:13], Daniel C. Sobral ([EMAIL PROTECTED]) wrote:
Bill Maniatty wrote:
First we want to get the mechanism of driver installation down, then
try our hands at writing our own driver. I fear that if we roll our own
driver software we may find that if we have errors (not that we
On Sun, 23 Jan 2000, Mike Smith wrote:
I can't agree with Mike Smith that reading the code is adequate. It
certainly doesn't apply to newcomers, but it doesn't even apply to
seasoned hackers like Mike: the BSD style doesn't provide for adequate
comments, and so what you see from
-On [2124 10:13], Daniel C. Sobral ([EMAIL PROTECTED]) wrote:
As long as a device is just inb/outb (I seem to recall newbus have a
replacement for these)
bus_space_read_#() / bus_space_write_#()
Where # is 1, 2, 4, or 8. But I don't think we support atomic 8 byte
atomic reads and writes.
-On [2124 10:13], William A. Maniatty ([EMAIL PROTECTED]) wrote:
Is it possible to get a look at the digital Unix guides, that might be a
good starting point. Are they on line (perhaps you have a URL)?
-On [2124 08:01], Chuck Robey ([EMAIL PROTECTED]) wrote:
The problem is, you can't even find what the interfaces are. Reading the
code isn't very useful if you can't even find the right place to start
from. At least the interface points could be listed, so that someone
would know where to
In message [EMAIL PROTECTED] Jeroen Ruigrok/Asmodai writes:
: As long as a device is just inb/outb (I seem to recall newbus have a
: replacement for these)
:
: bus_space_read_#() / bus_space_write_#()
:
: Where # is 1, 2, 4, or 8. But I don't think we support atomic 8 byte
: atomic reads and
-On [2124 19:55], Warner Losh ([EMAIL PROTECTED]) wrote:
In message [EMAIL PROTECTED] Jeroen Ruigrok/Asmodai
writes:
: As long as a device is just inb/outb (I seem to recall newbus have a
: replacement for these)
:
: bus_space_read_#() / bus_space_write_#()
:
: Where # is 1, 2, 4, or 8.
In message [EMAIL PROTECTED] Jeroen Ruigrok/Asmodai
writes:
: So my statement was actually more in reflection to NetBSD's support of
: it. Whether or not they support busses which do 8 byte atomic
: reads/writes I am not sure of.
:
: Thanks for the reality adjustment Warner. =)
Yes. Looking
Mike Smith wrote:
Writing documentation is a resource-sucking nuisance; supporting outdated
documentation even more so. The BSD driver model is sufficiently simple
I think that there might be a compromise
solution: when someone learns the interface
from analysing the code he might as well
On Sunday, 23 January 2000 at 22:35:53 -0800, Mike Smith wrote:
I can't agree with Mike Smith that reading the code is adequate. It
certainly doesn't apply to newcomers, but it doesn't even apply to
seasoned hackers like Mike: the BSD style doesn't provide for adequate
comments, and so what
On Monday, 24 January 2000 at 2:44:43 -0500, William A. Maniatty wrote:
Hi There:
Chuck Robey Writes:
I know where Mike's coming from. Wait until the next guy posts on the
list "I don't really know how to program, but please tell what 'C' is, and
how to write a device driver". We had a
On Monday, 24 January 2000 at 2:28:23 -0500, Chuck Robey wrote:
On Mon, 24 Jan 2000, William A. Maniatty wrote:
Both Chuck Robey and Mike Smith have some points, but that won't
stop me from giving my opinion :-). Mike is correct that experience is
key to being a solid systems software
On Monday, 24 January 2000 at 7:09:35 -0800, Mike Smith wrote:
On Sun, 23 Jan 2000, Mike Smith wrote:
I can't agree with Mike Smith that reading the code is adequate. It
certainly doesn't apply to newcomers, but it doesn't even apply to
seasoned hackers like Mike: the BSD style doesn't
On Monday, 24 January 2000 at 10:04:10 +0100, Jeroen Ruigrok/Asmodai wrote:
-On [2124 08:01], Mike Smith ([EMAIL PROTECTED]) wrote:
I can't agree with Mike Smith that reading the code is adequate. It
certainly doesn't apply to newcomers, but it doesn't even apply to
seasoned hackers like
-On [2123 11:11], Greg Lehey ([EMAIL PROTECTED]) wrote:
[adding -doc, which is more appropriate for some of the questions]
On Saturday, 22 January 2000 at 23:06:41 -0500, Bill Maniatty wrote:
I have a student this semester in my Operating Systems class who would like
to become a bit more
Hello Jeroen:
Jeroen Ruigrok (in response to Greg Lehey and myself):
-On [2123 11:11], Greg Lehey ([EMAIL PROTECTED]) wrote:
[adding -doc, which is more appropriate for some of the questions]
On Saturday, 22 January 2000 at 23:06:41 -0500, Bill Maniatty wrote:
I have a student this
On Sun, 23 Jan 2000, Bill Maniatty wrote:
Definately not an ethernet card. *g*
Seems no-one can keep up with Bill Paul in that aspect. =)
We probably could not compete :-), but we are interested in ethernet
card drivers (at some point) and would like to learn.
You could try usb
Actually the lack a reference or tutorial document is kind of damning
in a way, since it gives hardware vendors a powerful excuse not to
support FreeBSD in the way that say Lin*x is supported.
We have a better solution; they just give us the documentation and we
write the drivers for them.
Mike Smith Writes (in response to me):
Actually the lack a reference or tutorial document is kind of damning
in a way, since it gives hardware vendors a powerful excuse not to
support FreeBSD in the way that say Lin*x is supported.
We have a better solution; they just give us the
On Sun, 23 Jan 2000, Jeroen Ruigrok/Asmodai wrote:
A possibly better alternative is to find a device which isn't
currently supported by FreeBSD and write a driver for it. This would
have the advantage that the work would also be a contribution to
FreeBSD. The question that I can't answer
I'd also concentrate more on the relatively completely newbused
drivers:
dev/ed
dev/ep
dev/sn
and ignore the incomplete ones, of which only one comes to bind (aha).
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of
On Sunday, 23 January 2000 at 11:48:39 -0500, Bill Maniatty wrote:
Hello Jeroen:
Jeroen Ruigrok (in response to Greg Lehey and myself):
-On [2123 11:11], Greg Lehey ([EMAIL PROTECTED]) wrote:
2) Choose a non-essential device with a simple preexisting driver.
3) Remove all trace of the
I can't agree with Mike Smith that reading the code is adequate. It
certainly doesn't apply to newcomers, but it doesn't even apply to
seasoned hackers like Mike: the BSD style doesn't provide for adequate
comments, and so what you see from the code is mainly tactics, not
strategy.
You
On Sun, 23 Jan 2000, Mike Smith wrote:
I can't agree with Mike Smith that reading the code is adequate. It
certainly doesn't apply to newcomers, but it doesn't even apply to
seasoned hackers like Mike: the BSD style doesn't provide for adequate
comments, and so what you see from the
Chuck Robey writes:
On Sun, 23 Jan 2000, Mike Smith wrote:
I can't agree with Mike Smith that reading the code is adequate. It
certainly doesn't apply to newcomers, but it doesn't even apply to
seasoned hackers like Mike: the BSD style doesn't provide for adequate
comments, and so what
On Mon, 24 Jan 2000, William A. Maniatty wrote:
Both Chuck Robey and Mike Smith have some points, but that won't
stop me from giving my opinion :-). Mike is correct that experience is
key to being a solid systems software developer, who writes device drivers.
Now the next question is how
On Mon, 24 Jan 2000, William A. Maniatty wrote:
Actually a document with a step by step development of a very simple
driver might actually tell someone how to write a driver AND give them
their first experience at writing a driver :-).
The Digital Unix device driver writers guides are kinda
Hi There:
Chuck Robey Writes:
I know where Mike's coming from. Wait until the next guy posts on the
list "I don't really know how to program, but please tell what 'C' is, and
how to write a device driver". We had a pretty nasty flamewar over that
maybe (I think) 9 months ago, and it still
Matthew Dodd wrote:
[stuff about stepwise refinement approach deleted]
The Digital Unix device driver writers guides are kinda nifty like that.
Is it possible to get a look at the digital Unix guides, that might be a
good starting point. Are they on line (perhaps you have a URL)?
Is it
Hello All:
I have a student this semester in my Operating Systems class who would like
to become a bit more knowledgeable about systems software. I suggested
that he learn a bit about how device drivers are written in FreeBSD
as a minor project. My questions are:
1) Does any current
[adding -doc, which is more appropriate for some of the questions]
On Saturday, 22 January 2000 at 23:06:41 -0500, Bill Maniatty wrote:
Hello All:
I have a student this semester in my Operating Systems class who would like
to become a bit more knowledgeable about systems software. I
33 matches
Mail list logo
