From: Stephen Hemminger <shemminger@osdl.org>
To: Nicholas Jefferson <xanthophile@gmail.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: <REAL> iBurst (TM) compatible driver
Date: Tue, 1 Nov 2005 15:21:28 -0800 [thread overview]
Message-ID: <20051101152128.121792bf@dxpl.pdx.osdl.net> (raw)
In-Reply-To: <4cd031a50510312100n23bffa13jb48a6daa33bce80b@mail.gmail.com>
On Tue, 1 Nov 2005 16:00:19 +1100
Nicholas Jefferson <xanthophile@gmail.com> wrote:
> Hi Stephen,
>
> Thank you for your comments. A new version of the iBurst (TM) wireless
> compatible driver (and a patch against 2.6.13.4) is now available [1]
> under the linux-2.6-ibdriver-2.0 release.
>
> [1] http://sourceforge.net/projects/ibdriver
>
> > 1. Your network device registration code is wrong.
>
> Okay. ib_net_register now uses alloc_netdev with the appropriate
> changes elsewhere.
Where is updated code?
>
> > 2. Transmit routine is wrong. Drop packets if out of memory.
>
> Okay. ib_net_tx_start does not allocate memory now.
>
> > 3. You need to flow control the transmit queue.
>
> ib_net_tx_prepare already did netif_stop_queue and netif_wake_queue.
> Would you prefer this to be in ib_net_tx_start instead?
There is still a race with poll and tx_start.
Better to have tx_start check for space after queuing and have
poll wake_queue when space becomes available.
> > 4. WTF is the whole ib_net_tap file stuff, and why do you need it?
>
> The modem can return status information (signal strength, etc.). This
> information is accessed from usermode by device files. There is also
> an interactive "talk" channel to control the modem, but I don't know
> what it can do. The ib-file module implements these device files. It
> is not essential for the driver and we don't yet know the modem
> protocol anyway, so I've removed it.
Some possibilities:
1. Could you support a subset of the existing wireless functions. Then
all the cool tools like wireless strength stuff would work.
2. Or add a sysfs status files
3. Or a /proc file per device
It makes sense for the driver to give as much information to the user
as possible. Just try and use existing API's first.
> > 5. Why bother with a /proc interface?
> > 6. If you must then use seq_file.
> > 7. If you must then do one device per file.
>
> The /proc interface was for debugging and may later be used to provide
> the status information instead of the device files. It's not
> essential, so I've removed this as well.
One way I use is to keep a separate patch around that adds in the
/proc stuff for when debugging, but not put it in the main kernel.
> > 8. Then you can get rid of having a global array of device structures
> > which is hard to maintain properly.
>
> The global array was used to set up the correspondence between the
> device files (via the minor device file numbers) and the modem
> structures (via the index to the global array). It's gone now ;-)
>
> > 9. If you don't support ioctl's just leave dev->ioctl as NULL
> > 10. Error code's from call's like register_netdev() should propogate back out.
> > 11. ib_net_open, ib_net_close only called from user context don't need
> > irqsave use spin_lock_irq()
> > 12. Coding style: don't use u_long it's a BSDism
> > 13. Please have source code laid out as patch to kernel, not out of tree driver
>
Also.
* Default name should be "ib%d" so you can handle multiple cards without
getting an error.
* Why so many symbols exported?
* Ethtool and standard message level support would be cool (but not required).
--
Stephen Hemminger <shemminger@osdl.org>
OSDL http://developer.osdl.org/~shemminger
prev parent reply other threads:[~2005-11-01 23:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-27 16:24 <REAL> iBurst (TM) compatible driver Nicholas Jefferson
2005-10-27 17:07 ` John W. Linville
2005-10-27 17:44 ` Andi Kleen
2005-10-27 17:45 ` Lennert Buytenhek
2005-10-27 21:25 ` Bongani Hlope
2005-10-27 22:31 ` Stephen Hemminger
2005-11-01 5:00 ` Nicholas Jefferson
2005-11-01 23:21 ` Stephen Hemminger [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20051101152128.121792bf@dxpl.pdx.osdl.net \
--to=shemminger@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=xanthophile@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).