[openbeosnetteam] Re: Dial-Up
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Thu, 10 Apr 2003 01:41:30 +0200 CEST
Philippe Houdoin <philippe.houdoin@xxxxxxx> wrote:
> In reply to Axel Dörfler:
> > Philippe Houdoin <philippe.houdoin@xxxxxxx> wrote:
> >> - about a Object Oriented (C++) stack design, but as BeOS kernel
> > > (and
> >> OpenBeOS 's one most probably) linker don't support that well C++,
> > > we
> >> code
> >> our stack in C++ but C only.
> > If you prefer C++, use C++. We don't have exceptions, but almost
> > anything else will work.
> IIRC, last time we discuss via IRC this issue you told me that
> we'll not have class heritage full support too (vtable issue?).
> OO C++ in a stack make sense in particular for protocols and
> interfaces
> modules, but also for sockets. But it'll need heritage, not only
> classes.
I might have mentioned RTTI, but (multiple) inheritance is working.
Only features which need runtime support (like RTTI and exceptions)
would require some work, all the other stuff works nicely.
So if you prefer C++, go ahead, no one will stop you. I actually prefer
to have C++ in the kernel for many things, because you can use the
object creation on stack method to write much cleaner and more robust
code (resources are automatically freed when allocated on the stack).
Not to mention the type safety C++ has.
Not that I would want to push you into that direction :-))
> > It can't achieve this alone. The networking drivers would have to
> > be
> > changed for this - the read/write functions of the driver mustn't
> > be
> > used when want to remove all copies (since we can't remove the one
> > that
> > happens when the recv() function is called).
> Yes, but I was refering to copie(s) done in the stack, not outside.
> Network drivers are currently wrapped by the ethernet module, like
> his BONE
> counterpart. We can't know how many, if any, copie(s) a driver do
> behind our
> back, that's sure.
>
> Let's hope new net card drivers will come in near future and their
> coders will
> keep that point in mind, especially as 1Gb ethernet and very high
> speed devices
> can't really afford to waste bandwidth by badly driver coding
> practice...
Well, Gigabit cards will require new drivers, so it should be possible
to be aware of this need while writing one :-)
IIRC even I don't copy data around in my SiS 900 driver more than
needed ;-)
> > We could also provide a zero copying userland C++ API - that would
> > be a
> > nice advantage over using the standard BSD socket API.
> You mean, thru BNetPacket class or a new one?
> Or do I miss totally your point here?
I am not that familiar with the Net Kit's C++ API to be able to say if
that would be possible, but it's the direction I intended to go :-)
> > > My own taste is for using iovec like the bone_data.
> > > In the new stack skeleton zipfile, look for stack/data.[ch] for a
> > > uncomplete
> > > bone_data-like implementation of what I've called net_data.
> > > It include net_data_queue support, too.
> > I guess they both are almost the same in the end, just the name
> > differs. Although, of course, it might make sense to add some more
> > possibilities to them, like bone_data obviously does.
> Yes, there is much more to offer in my net_data than that.
> Splitting a net_data in two, cloning (share the data chunks),
> duplicating it
> (copy the data chunks too, the zero-copy paradigm nightmare!), and in
> the
> future locking & mapping the data chunk in physical memroy for
> hardware driver
> needs.
Sounds very nice!
Adios...
Axel.
Other related posts:
