netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

      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).