David S. Miller ([EMAIL PROTECTED]) writes:
>
> Now that's some ugly code...
>
Thanks. The ugliness is inversely proportional to the amount of coffee I've had.
I know a lot of programmers who, like me, are very self-consious about their work.
They are never really satisfied with their work, know that it could be done
better/faster/smaller, and are almost scared to show their work to anyone for
fear of being laughed at no matter how good the code may be.
And now that I finally have software that I feel confident in what happens?
I get slapped in the face by God himself.
I understand your gut reaction to the press release, especially with the number
of companies who are trying to "make a buck" off of the Linux bandwagon
I get as pissed off as any other member of the community when I see companies take
advantage of Linux.
My partner and I quit our jobs 5 years ago to port some cool control system software
we wrote from the Amiga to Win 95. Well, it turned out that Win 95 didn't cut it
and we needed food, so we decided to do some Web publishing. That's when we discovered
Linux.
Our company grew up with Linux. Web publishing led to our Web server (Linux) which
led to Samba, and so on. We started off doing a lot of local contracting jobs
with Schools, Libraries, ISPs and business customers installing Linux servers and
firewalls.
I've been coding a long time. Most projects I've done up until now have been
Web and other custom jobs. I've never really had anything that was usefull for
the masses.
We took over the SDL WAN card development about 2 years ago when SDL said they
were going to stop supporting and developing for Linux. I had made a few simple
fixes to the N2 driver in the past and thought I could take on the project. We
already had a half-dozen or so customers with about 20 cards in use. If nothing
else, we needed to be able to solve our own customer's problems.
SDL was coming out with some cool 4 and 8 port T1 cards and HSSI was coming
soon. One of our local ISPs really wanted the HSSI card so as usual customers
with pizza money lead the development.
We had to sign some crappy NDAs with SDL to be able to use their WANic DDKs.
That's the reason we can't distribute the source code to everything. I hope the
new company that just bought SDL will be more receptive to our pleas for
Free Software.
The original N2 drivers had the protocol stacks (Cisco HDLC, PPP, Frame) built
into the hardware module.
It was very difficult to run multiple protocols and multiple cards. I knew
that this approach wouldn't work with the myriad of WANic cards that were
being planned.
So I split up the monolithic drivers into separate hardware and protocol modules.
And now it's about a year later, A year full of all-nighters and 3 A.M. support
calls and many proud moments after we'd turn up a DS3 circuit and see the traffic
start flowing.
My code works. It's not perfect. But it has performed its job far better than any other
WAN drivers I've ever seen.
The code is at a point in time where it needs a re-write. It has been shaped and
reshaped
into its current form mostly by the sales department. You know, they want to sell
what hasn't been developed yet. I've seen the Linux kernel take on some amazing
transformations during the development stages (usually after a production release like
2.0, 2.2). Structures are reworked, major semantic changes are introduced, whole
subsections are rewritten.
It's time for the code to take on the outline from our SAND whitepaper.
The Linux kernel can benefit from many parts of our code. Implementing the entire thing
as it's written would be a dumb thing to do.
Lets face it, the current Linux WAN code needs a major face lift. Most of it will only
work with the low-end Sangoma cards.
I think we need to get serious about implementing a WAN archetecture that provides
seamless support for all vendor's WAN cards, much like the ethernet subsystem (eth0
may be an EEPro 100 and eth1 may be a DEC Tulip card).
My code provides this support. It ain't perfect, but it is proven in the field and
there
are many ideas that could be used and incorporated into the main tree.
> If it helps WAN people write WAN drivers, so be it, but it's
> not something I'd like to let into the main tree. I mean,
> they redirect kmalloc calls, kmalloc of all things.
What the heck are you talking about? Where am I doing such an idiotic
thing?
> What they
> really are trying to do is have only to port this SAND DDK thing
> if we make changes in the kernel, and never have to touch the drivers
> themselves. So essentially they make their own binary driver interface
> to decrease the amount of recompilation they need to do.
Not really. I make changes to the sand core about as often as I modify individual
hardware drivers and protocol drivers. The amount of recompilation is not reduced
at all under these circumstances. Actually, I have it pretty easy right now.
I go to one directory and compile 8 different packages (SMP, UNI, different kernel
versions, etc).
Placing the core in the main tree means that I've got potentially serious version
control problems.
I hate binary driver releases. I'm one of those guys who will beat the hell out
of a company for source code especially for Linux software.
I hate the position I'm in because my hands are tied.
I can't release the WANic source code because of that damn NDA with SDL. I also can't
release the Frame Relay source (as written) because of similar licensing problems.
So I rewrote the crap they had with a design that allowed me to release as much of the
source code as I legally could.
I've been releasing the source code to my stats program and pppd modifications since
day 1.
>
>
> Redirecting things like kmalloc is actually potentially bad for
> performance. For example, say some day we use inline macro expansion
> and GCC's builtin_constant_p() on the length being requested to figure
> out the SLAB pool at compile time. With kmalloc call redirection,
> they won't get that optimization. Same goes for potential SMP
> lock and atomic operation implementations, often the code can be
> compiled in a significantly more efficient manner if constants and
> other invariants are exposed.
>
>
I agree. I didn't know I was doing it. And the only reason the locking calls
are done as an inline function is to be able to log/debug the locking
code. That should be cleaned up.
> So perhaps their press release is really about making binary only
> drivers more feasible and maintainable. It's quite pointless, they've
> just moved their problem into another place, instead of having to have
> different individual driver binaries when kernel APIs change, one
> needs to get a new recompiled version of their silly library. It
> hasn't solved the problem, is just makes it different.
Of course it hasn't solved the problem. The problem is weak WAN driver support
under Linux. Don't you want to see Linux shine in this area? I sure do.
I'd like to help. I think I can help. Not as much right at this moment as
my wife is 38 weeks pregnant and my 2 year old loves pulling on these cables
that are strewn everywhere.
>
>
> It's much like the "DDK like" thing SCO and others were pushing for
> a Linux implementation of, the core incentive is the same, make binary
> only drivers more feasible under Linux. This is why all of these
> efforts tend to smell bad to me.
>
No that's not it at all. After reading our own press release I can see why you
might feel that way.
I HATE BINARY ONLY DRIVERS DAMNIT! Ok, sorry, I'm a little worked up and in
need of some sleep.
I think we can merge ideas into a killer architecture that works for all
WAN card vendors.
But SDL is not the only hardware vendor with licensing issues. There will be
others who run into the same problems as we face. We're just a Linux company.
Always have been. We don't make the hardware. We are a team of networking
specialists who can write software and install and support networks.
It's not easy when your company lives week to week and is always on the verge of
going out of business. We've worked our butts off for many years now, and
we finally have something of worth to give back to the community.
>
> It's amusing how so many companies want to have that Linux checkbox,
> and the extremes they'll go to in order to retain binary only drivers
> at the same time.
>
Like I said, Always been a Linux company, Always will be.
And I went to extremes to break up the drivers so we could release the important parts!
The fact is, is that if a company needs the code to the WANic 600/800 card they
can sign the same damn NDA we did and they will get the code.
I hate being restricted like this, but what more can I do?
I guess I shouldn't have developed a single line of code. Then there wouldn't even
be any WANic/Aries 400/405/500/505/550/555/604/608/654/658/800/805/850/855 drivers
for Linux. You'd have to run NT (as if).
>
> Later,
> David S. Miller
> [EMAIL PROTECTED]
I'm sorry for the rant. I feel better now.
My company really does have something to offer the Linux community. I look forward
to helping out in any way I possibly can.
Thanks,
Scott Yoder
Director of Engineering
ImageStream Internet Solutions, Inc.
E-mail: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
