headers
Peter.Bex | 2 Sep 2002 13:32
Picon
Picon

My MTD driver

Hello all,

I'm a complete newbie in kernel hacking, but since my networking card (MTD
803) isn't supported by NetBSD I decided to create my own driver.
I actually got quite far with the datasheet and of course the NetBSD
source for other drivers, but now I've stumbled across a few problems that
keep me from getting the driver finished.

Could someone please post (a link to an) explanation of how mbufs work,
because I'm completely mystified by what the other drivers are doing
here.
And how does bus_dmamem/bus_dmamap stuff work? I have downloaded a paper
by Jason R. Thorpe, which explains how this should be implemented, but
I still don't really grasp how I should use them.

Also, on a side note: I noticed that some drivers do a lot of things in
code, for which there are generic functions. For example, some drivers
calculate the CRC32 hash, but there's also a ether_crc32_?e function which
does exactly that (for example, sys/dev/ic/hme.c). Can this be considered
a bug?

Regards,
Peter Bex
Permalink | Reply | 1 comment |
headers
itojun | 2 Sep 2002 13:42

Re: My MTD driver

>Could someone please post (a link to an) explanation of how mbufs work,
>because I'm completely mystified by what the other drivers are doing
>here.

	I would recommend the following book.

itojun

TCP/IP Illustrated, Vol. 2 (top)

Authors: Gary R. Wright, W. Richard Stevens
Publication: Addison Wesley, 1995 (ISBN 0-201-63354-X)
Permalink | Reply | 0 comments |
headers
M. Warner Losh | 3 Sep 2002 00:50

Re: 802.11

In message: <20020827000446.T16306 <at> dr-evil.shagadelic.org>
            Jason R Thorpe <thorpej <at> wasabisystems.com> writes:
:  > 	So far the CVS conflits have been trivial to resolve, (great minds
:  > think alike?). However, I would like to coordinate with whomever is also
:  > working on the ieee802.11-related code so that we don't hose or re-invent
:  > each-other's work.
: 
: Send your patches in via send-pr ... I'll probably handle them.
: 
:  > 	Could y'all out there in 802.11-land please get in touch with me
:  > via return email?
: 
: ...and feel free to send me email about this stuff :-)

I have a long term goal of seeing a merged (or at least mostly common)
{Net,Free,Open}BSD 802.11 stack, similar to some of the items in
onoe-san's list.  It would be good to have a common infrastructure
that we can all leverage.  It would also be cool to have an effective
daemon that could do more complex things than the standard says
(filtering based on MAC address, doing different types of packet level
encryption, 802.1x, and other experimental things).

It would also be good to have a common interface to set the output
power of the cards (for those that support this).  Maybe there's
enough interest to have a specific list on this.

Warner
Permalink | Reply | 0 comments |
headers
Jason R Thorpe | 3 Sep 2002 01:45

Re: 802.11

On Mon, Sep 02, 2002 at 04:50:45PM -0600, M. Warner Losh wrote:

 > It would also be good to have a common interface to set the output
 > power of the cards (for those that support this).  Maybe there's
 > enough interest to have a specific list on this.

You mean mailing list?  Why not use bsd-api-discuss <at> wasabisystems.com?

--

-- 
        -- Jason R. Thorpe <thorpej <at> wasabisystems.com>
Permalink | Reply | 0 comments |
headers
M. Warner Losh | 3 Sep 2002 01:49

Re: 802.11

In message: <20020902164513.F6992 <at> dr-evil.shagadelic.org>
            Jason R Thorpe <thorpej <at> wasabisystems.com> writes:
: You mean mailing list?  Why not use bsd-api-discuss <at> wasabisystems.com?

Yes.  I was hoping it would be more than an API, which I thought would
be beyond the scope of that list.

Warner
Permalink | Reply | 0 comments |
headers
David Young | 3 Sep 2002 03:02

Re: 802.11


Is bsd-wireless <at> lists.bawug.org not the right list for discussions of
an 802.11 stack?

Dave

On Mon, Sep 02, 2002 at 04:50:45PM -0600, M. Warner Losh wrote:
> In message: <20020827000446.T16306 <at> dr-evil.shagadelic.org>
>             Jason R Thorpe <thorpej <at> wasabisystems.com> writes:
> :  > 	So far the CVS conflits have been trivial to resolve, (great minds
> :  > think alike?). However, I would like to coordinate with whomever is also
> :  > working on the ieee802.11-related code so that we don't hose or re-invent
> :  > each-other's work.
> : 
> : Send your patches in via send-pr ... I'll probably handle them.
> : 
> :  > 	Could y'all out there in 802.11-land please get in touch with me
> :  > via return email?
> : 
> : ...and feel free to send me email about this stuff :-)
> 
> I have a long term goal of seeing a merged (or at least mostly common)
> {Net,Free,Open}BSD 802.11 stack, similar to some of the items in
> onoe-san's list.  It would be good to have a common infrastructure
> that we can all leverage.  It would also be cool to have an effective
> daemon that could do more complex things than the standard says
> (filtering based on MAC address, doing different types of packet level
> encryption, 802.1x, and other experimental things).
> 
> It would also be good to have a common interface to set the output
(Continue reading)

Permalink | Reply | 0 comments |
headers
Atsushi Onoe | 4 Sep 2002 03:54
Picon
Picon

SIOCSIFADDR

> Modified Files:
> 	syssrc/sys/netinet: in.c
> 
> Log Message:
> avoid SIOCSIFADDR if there's an IPv4 address already.
> the comment doesn't match the behavior, it seems that the code assumed that
> there's only one IPv4 address on an interface.  sync w/kame

I'm curious to know what is the intention of this change?
Why not just fix the comment?
Although SIOCSIFADDR is designed for single IPv4 address per interface,
it would be halmless that give the driver additional chance.

I don't think new code is wrong, but the change looks unnecessary for me.

Atsushi Onoe
Permalink | Reply | 4 comments |
headers
Jun-ichiro itojun Hagino | 4 Sep 2002 04:05

Re: SIOCSIFADDR

>> Modified Files:
>> 	syssrc/sys/netinet: in.c
>> 
>> Log Message:
>> avoid SIOCSIFADDR if there's an IPv4 address already.
>> the comment doesn't match the behavior, it seems that the code assumed that
>> there's only one IPv4 address on an interface.  sync w/kame
>
>I'm curious to know what is the intention of this change?
>Why not just fix the comment?
>Although SIOCSIFADDR is designed for single IPv4 address per interface,
>it would be halmless that give the driver additional chance.
>
>I don't think new code is wrong, but the change looks unnecessary for me.

	additional SIOCSIFADDR will reset the interface, makes it unable to
	communicate for certain period of time (for some interfaces).

itojun
Permalink | Reply | 1 comment |
headers
Atsushi Onoe | 4 Sep 2002 04:14
Picon
Picon

Re: SIOCSIFADDR

> 	additional SIOCSIFADDR will reset the interface, makes it unable to
> 	communicate for certain period of time (for some interfaces).

Isn't it a bug of the interface?  Changing the IPv4 address if it is
the only assigned to such interface still bother existing non-IPv4
communication.

Atsushi Onoe
Permalink | Reply | 0 comments |
headers
enami tsugutomo | 4 Sep 2002 05:10
Picon
Picon

Re: SIOCSIFADDR

Atsushi Onoe <onoe <at> sm.sony.co.jp> writes:

> Why not just fix the comment?
		:
> 
> I don't think new code is wrong, but the change looks unnecessary for me.

I think the commet matches to the existing (i.e., rev. 1.77, not 1.78)
code.

The in_ifinit calls ifioctl SIOCSIFADDR for every address assigned and
I guess the comment want to say that

	- callee will initialize if it finds that the address is the
          first one.
	- callee will validate the address if necessary.

If a callee really need to validate an address, just doing it only for
the first address doesn't make sense.

enami.
Permalink | Reply | 1 comment |

Gmane