Krzysztof, thank you for taking the time to look at my driver
and for answering my Linux questions over the last few months.
> Not sure (that's your drivers and hardware) but you may consider
> letting the old driver stay for a while, to enable users to
> make a smooth transition. Especially if the old driver is working.
I don't want to inconvenience current users.
I have no objection to keeping the old driver around for a while.
I don't know how many Linux users of the old driver are out there.
The FreeBSD version of the old driver was so out-of-date that it
was removed; NetBSD immediately discarded the old driver when I
submitted this driver. OpenBSD is still thinking about the whole
matter; I think they have put a lot of work into the old driver
and don't want to abandon it.
My home Internet connection is a T1 circuit using one of my LMC
T1 cards and this device driver. I rewrote the driver because
I found it to be very fragile. The link would start correctly
about 3 out of 10 times, and if I unplugged the T1 cable and
plugged it back in, the old driver would never recover.
It was embarrassing; I knew the hardware was better than that.
> It doesn't conform to the formatting rules (tab width = 8,
> brackets etc).
If you insist, I will run it through scripts/Lindent before submitting.
This will make it more difficult for me to keep it in sync with the
three other operating systems. FreeBSD and NetBSD did not object to
my admittedly non-standard formatting.
> I think you have to strip non-Linux code (massive amounts
> #defined out).
The same two source files compile on Linux, FreeBSD, NetBSD and
OpenBSD. I intend to maintain this driver and keep it in sync
across OSs, so I would rather not strip out the BSD code. I tried
to minimize the number of "#if FOO" statements and I added comments
attempting to make it clear which kernels used which code.
The old lmc driver is factored into many small files in an attempt
to exclude code for other OSs. Andrew Stanley-Jones, who wrote it,
worked for me and I told him to do it that way. I have since changed
my mind; I think it is better to have less files and use compiler
directives.
> Not sure why are you using syncppp both directly and with my generic
> HDLC (which, for PPP, uses syncppp).
Each operating system has its own line control protocol stack(s);
my driver deals with them all. At Kconfig time you can select
which stacks you want. If SPPP does all you need, then you can
configure the driver to use only SPPP (and the code is smaller).
You can also configure the driver to not use any external line
protocol stack, and instead use a built-in "null protocol": rawip.
> The same applies to "rawip". It only complicates code.
I find rawip mode VERY useful for driver testing. It doesn't
depend on any external package in any OS, which simplifies
configuration when I am testing. Since it is the "null protocol"
it gives a performance upper bound for the driver. It is a tiny
amount of code.
> sc->hdlcdev->proto.id in gen_hdlc_watchdog() is quite internal
> to generic HDLC. Why are you doing that?
The driver configuration program reports the currently-selected
line protocol to the user. hdlcdev->proto.id is public, so...
> gen_hdlc_open():
> Obviously it gets parameters from userspace with copy_from_user().
> Why do you want to interact with generic HDLC settings (PPP etc)?
> And if you really want it, why are you doing it in your driver
> instead of using existing ioctls from userspace (the ones which
> sethdlc uses)?
Each protocol stack on each operating system has a different method
to change line protocols and set line protocol-specific params.
One OS, which shall remain nameless (not Linux), has NO way to
change line protocols! So the driver and its configuration program
have learned how to change line protocols in the various stacks.
I tried to extend the ability of the driver config program to
change line protocols to the generic-HDLC stack. Protocols are
changed by calling hdlc_ioctl(), which seemed easy. But then I
discovered a problem: hdlc_ioctl() fetched settable protocol params
from user space. But! PPP didn't have any settable params, so
the driver COULD switch to PPP, it just could not switch to any
OTHER protocols. So I put a comment in the code and planned to ask
you to change hdlc_ioctl() so that it used default params if the
user-space pointer was NULL. Then, my driver and its config program
could change protocols in simple cases without needing the sethdlc
program. This is a very minor thing and I have no problem ripping
it out. I was trying to make the driver work uniformly across all
OSs.
/David Boggs
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
