|
Writing Network Drivers |
BRAD TAYLOR: This is obviously the Writing Network Drivers talk. I'm Brad Taylor, I wrote most of the networking code that you use on the BeOS, everything except for the standard Berkeley programs, you know, telnet, FTP, those are ported, all the TCP stacks and all the drivers, I did that.
So anyway, it's a lot of work for one person to do, so the DR9, I put in a network driver API so that you guys can help make the BeOS support all different kind of cards, because I obviously cannot do all this work myself.
All right, so I'm going to tell you in
this talk how to write an ethernet driver; I'm not
going to tell you exactly how, of course, because you
have to leave something to the imagination. I will
tell you how to write what I call an IP driver, what
this really is is a driver for a device that is not
ethernet, so it could be ATM, PPP, SLIP, also how you
can add your own non-IP protocol to BeOS, whether it be
AppleTalk, NetWare, whatever you want. Okay.
So we start off with the ethernet driver,
I think most people are interested in doing ethernet
drivers, based upon the feedback I have received. All
different kinds of cards that people would like to see
supported. There are two components to an ethernet
driver on BeOS. There is a traditional driver, real
kernel driver, it's in the same address space as the
kernel, it can access the hardware. Then you have an
add-on to the Net Server, this is the API I'm going to
talk about today, it's a C++ API, that's how the Net
Server sees your device. How you communicate with your
hardware, how you get down to the real kernel drivers
is your own business, that's a private API.
The add-on itself has two main functions; one is to configure the card, and in that case it's actually an add-on to the network preferences application, which people use to configure IP addresses and such.
And then the second function of the add-on is to actually operate the card, and in that case it's an add-on to our Net Server. For those of you who aren't familiar with how networking works on Be, most of the networking code runs as a user program called a Net Server, so that's why there is this kernel component and the add-on for the Net Server, they are different address spaces. The fact that it runs in user mode makes it easy to do a lot of these things because you can, you know, you can read and write files for debugging or whatever, you can put up UI, as in the case -- it's not an ethernet but for PPP UI comes up every now and again to ask you what your password is or whatever.
Go to the next slide.
So start off with configuring an ethernet
driver, your add-on will have a function in it, an
entry point called open_config. And what you return is
an object called BNetConfig, and that object has just
a handful of methods in it. The first one is IP
device, if you are an ethernet driver you always return
to null or false; if you are one of these things that I
call an IP device, obviously you return true in that
case. Then there is a thing called Config, and this is
when the network preference panel asks you to configure
the card.
Let me just show you a little example of that, not a great example, but an example nonetheless. Here is a network preference panel, and I say add interface here, and a list of -- these are a list of add-ons that come on, network server add-ons. One of them is, you know, here is the DEC 21040, 21041 PCI adapter, has a button there called Device Configuration. That config method is called when that button is pushed. Currently we have nothing to configure here, but in theory you could configure to say what kind of connector do I have, or how much memory, how big do you want the DMA buffers to be, all that. On a BeBox I could show you for an ISA card you are forced to configure I/O ports and things like that for an NE2000 card. This is a Mac, so those don't display at all. The drivers are actually on here, but they return null most Mac people aren't really interested in ISA cards, so they don't display.
So the arguments there to Config are what is the interface name, and that's something that the network preference panel will make up and hand to you. It's just sort of a cookie into this net_settings object. And you can think of that, the net_settings as a -- you can think of the Net Settings as a group of settings, each of which has a heading and a group of key value pairs for each heading. We will get into more of that later, but what you do with the config is you pass that name, points to the net setting and a callback handler, which is an object really that represents the network callback preference application itself that you can call back when you are done. Basically you configure stuff you store back into the net settings thing, whatever you need to store. Then if you successfully did it you will call into the callback handler and call the done routine at the bottom, indicating whether, you know, B_NO_ERROR if everything went okay or be error, whatever kind of error you want, if something didn't quite go right. Perhaps the user canceled, they changed their mind, they didn't want to configure that card, you can't configure it, can't configure would be an example of this autoconfig variable or parameter which is if that's passed to you as true, it means just configure this card, do the best you can. With many things you can do that. With onboard PowerMac ethernet it works, there is really nothing to do. In this case of this DEC card we did it. With ISA cards it's kind of hard sometimes to configure. So you might just say, well, gee, I can't configure this card, I don't know what to do, you know, and the done thing will fail.
All right. That's it for configuration.
We go on to, this is a little bit more about the net
settings I was telling you about. This net_settings is
not a C++ object, it's really a C object. And you can
do two operations on them, you can look up one and you
can create one. And an example of that heading here
would be like for an interface might be called
interface0. And you want to find what the IP address
is on interface0, you would pass in the heading of
interface0, the name would be IP address, which is
just the standard thing that we use right now, and the
value will be filled in with the IP address, the
strings, just regular strings, of what's currently
stored in your Net Settings. In this net_setting
object. If it's null it refers to the settings that
are set in the file that have been saved. If it's not
null, then it refers just to this memory based thing
because the network preference panel, if you press save
it will actually save those into the file, but you can
cancel out of it. People can configure their
interfaces all they want and they may change their mind
and quit the application, they don't actually save,
nothing gets saved to file. It's a little different
from how the other preferences apps work on BeOS, just
exiting the application causes the preference to be saved.
So let me get to sort of the more of the
meat of things about an ethernet driver. So the entry
point for this, this is when the Net Server instead of
the network preference panel is opening up your add-on
is this open device, it passes you the name of your
device, which is actually the thing that was passed
before in the network preference called you, so it's
just one of those little cookie things to look up your
net settings. And you return a pointer to this BNetDevice,
which has a handful of methods here. The way
things normally work, like for -- we will talk about
transmission first, the Net Server will call into your
ethernet driver and say allocate a packet for me and
return a BNetPacket object, and the Net Server goes
and he fills in all the data he wants in that packet
and then he will call your SendPacket function, which
will send the packet off to ethernet and also free that
packet, you have got ownership of that packet.
ReceivePacket is, you know, for reception, the Net Server will basically be blocked on that method. And when a packet comes in, you know, you return that packet back to the Net Server and it will free the packet itself, it has ownership of that packet. We will go into more about what these BNet packets are later.
Then there are other functions to add and remove multicast addresses, to find out what the maximum packet size is, typically for ethernet it's 1514, but it can vary. There is a function here called a type, which you return, if you are an ethernet driver you always return the value B_ETHERNET_DEVICE, there is an enumerated list of types. We obviously don't know about all the various types of cards there can be. For Ethernet it's always B_ETHERNET_DEVICE. If it's something else and we don't know about it what this value actually is is the SNMP, so there is a standard for what these numbers are, we are just following that standard.
And then there is closing device, and what you are supposed to do there is cleanly close things, make sure no one else can call into your driver, return errors to receive packet and all that.
And then finally, the last interesting one is OpenIP, if you are an ethernet device you always return null in that case, if you are one of the things that I call an IP device then you return this BIpDevice object, which we will talk about later.
I was telling you about packets. The BNetPacket is a representation of, you know, you can
think of it as sort of a contiguous sequence of bytes,
with what we call a base, so when a packet comes in,
let's say ethernet packet is 1514 bytes, the base is at
zero, and then it gets out of ethernet and you strip
off the headers so you move the base up 14 bytes. And
when it goes through IP and it will mask off its header
and TCP will take it off and you finally get down to
data to the user. The base can also go the other way,
so when TCP is delivering data it will allocate a
packet from your driver, the base will get moved way up
and it will put in its header IP, IP will move the base
down, put in its header, then it goes to an ethernet,
ethernet writer that will put in the ethernet
information, it finally will go to your driver.
You don't have to worry about, if it's an
ethernet device, you don't have to worry about changing
the base around. You get entire packets that have a
base set at 0, or you should.
All right, so you can set the size of the
packet, you can get the size, I told you about the
base, that's the absolute value, the base method. The
set base is it takes a relative offset so it moves the
base relative to where it currently is. That's an
important distinction between the two.
Data block is somewhat complicated to explain. But it gives you a pointer to the data inside of the BNet packet, which is only valid, you know, while you retain ownership of that packet. So what you do is you get an offset, actually an offset from the base, that you want to start reading data at, you pass in a pointer to the size that you want to get, and DataBlock will return to you a pointer to that data but it may not be, internally it may not be contiguous, so the size will be updated to reflect how big the size it actually found is. So you may have to make several calls to DataBlock if you want to go through a packet. So it's a bit of an pain in the butt to use that, but it's faster, obviously, because you are getting a pointer. So if you don't want to go through all that there is these functions Read and Write. Ignore the one with the dangling comma there, that's obviously a mistake. But this Read here, Read and Write, they will eventually go through the data block several times till they get the size you requested or put in the size you requested. That's it for packets. I will have some more here.
So the ethernet drivers, all the drivers actually, can implement their own BNetPacket interface, that's basically a standard for if you return a BNetPacket object, here is the methods you need to implement it. Some of you may not want to implement your own packets, we have a package called BStandardPacket, it uses the equivalent of malloc and the bytes are contiguous. You can do that if you don't want to do the effort. In fact at Be right now all the drivers are using the BStandardPacket object.
We have a little utility function called copy_packet, it simply copies one packet to another, so you give it the source packet and an offset into that source packet and it's offset from the base, the destination packet and an offset into the destination packet and the size of the bytes that you want to copy. So it's basically taking a little segment from one packet and copying that into the other packet. Sometimes useful.
All right. So that's it for ethernet
devices. Now let's talk about IP devices for things,
PPP or ATM or whatever. They operate a little
differently. One of the differences is the first
method here, SendPacket, it's different than the one
for the ethernet device because it's passed in this
extra argument called DST, destination, that's actually
an IP address, so if you think about ethernet, when you
want to send an IP packet to someone, you have to
figure out what's their ethernet address, that's where
ARP gets involved, but that's device specific, so if
you are some other nonethernet thing it's up to you to
figure out how to convert the IP address to its final
destination, so that's why the extra argument is there.
And then also for reception, there is
nobody blocked on you, you will be called at a separate
thread and you will be blocked on run basically for the
life of the network server running and that's, it
passes you a pointer to the IP handler within the Net
Server that you are supposed to call into as packets
arrive.
Okay. So there is a few other random
things here, like, just like before you have to -- the
drivers is asked to allocate packets, that's a
allocpacket method and sendpacket, which is one of the
allocated packets given back to you. So there is a
flag argument, the only flags we have right now point
to point, sometimes it's interesting to know, for the
Net Server to know whether something is point to point
or not. If you are a point to point link you return
flags, otherwise you return 0. I can't find it here,
but it's in the header file that you can examine on
your CD. There is a packet size, how big of a packet
can you send, a close, and that's about it.
So there are some more about these
things. So here is the IP handler, when you get a
packet, when you get a packet -- I'm a little confused
about this, I apologize.
This is, this is a representation of IP in
the Net Server itself. So you can do things like you
can find out what the IP address is for that IP
interface, you can set the address like in the case of
PPP if you don't have an address and you need to do
that, you can find out what the net mask is. And you
can hand it packets, so you give it a pointer to the
packet and you will pass on a pointer to yourself. So
it knows where it came from. I think that normally
what you do for protocols and for these IP devices is
that you would call another packet as you -- it
basically takes the packet and starts asking all the
protocols are you interested in this guy? If you are,
and the protocols look and say well gee, I know about
ethernet, I like at the type field, looks like an AppleTalk
packet, okay, I'm interested; it looks at other
types, no, I don't want it.
So then we go on to protocols. Again
it's another add-on with an entry point called open_protocol,
you return this BNetProtocol thing and you
are passed in the name of yourself, which is actually
you can just ignore that argument, it's not really
important. You already know what the name of yourself
is, so that's why it's not important.
And so all this thing is you get this
BNetProtocol and as new devices come along, they are
passed to you, there is this AddDevice thing. You get
passed the device, I like ethernet, I will keep a
pointer to that; another device comes along and it's
PPP, PPP, no, I don't know how to deal with that, you
ignore it. You get a little list of devices that you
deal with and keep track of them. So that's kind of
interesting but you say well, gee, how do I get
anything done with that? That's where this comes in.
So the next thing you do is register what's called a
packet handler and there is again this little abstract
class which you will implement and your packet receive
method will be called when packets come in. There is a
register packet handler where you can register yourself
and as a priority defaults to 0. But you can set your
priority up, if you perhaps want to be first in that
chain of protocol receiving packets. The best example
I can think of for doing that, if you want to do
something like a packet sniffer you can bump your
priority up and you would be first in line with the
packet and also you look at the bits, you mark down
what's interesting, and then you would return from your
packet, receive method return a false saying I wasn't
interested in this packet, and so the Net Server would
go on to the next guy even though you were interested.
It just means -- the Boolean is really whether you take
the packet or not.
So all this stuff is kind of confusing, I
thought -- someone did a picture for me. I'm unable to
do this kind of stuff, only with my handwriting with a felt
pen on a piece of plastic. But anyway, someone who has
these skills did this picture. This shows all the
objects that we have described, so it is a simple case
of an ethernet device, you have the Net Server, let's
start you have application that wants to send data, it
sends a message to the Net Server with the data saying
send this data to TCP, the Net Server does all this
TCP stuff, IP, finally he has ethernet packet ready to
go and he hands it off to your BNetDevice, the green
thing there, then you simply hand it down to your
device driver to implement in the kernel. That's all
very simple. For an IP device it's not that much more
complicated, the same thing happens, the app sends the
data to the Net Server, puts on the TCP and IP headers,
but instead of adding on an ethernet header he just
hands it off to the BIpDevice which attempts to
designate an IP address, you figure out what to do with
your headers after that; then you go to your BNetDevice
for the ethernet thing, and possibly go down to
a device driver in the kernel.
For something like, for something like PPP you don't have to write the device driver because the serial port device is already there. The box at the bottom isn't always present for things like Slip and PPP.
Finally there is the yellow box over
there which is somebody is implementing a protocol. In
that case an app would not send data to the Net Server,
they would send data to your server sitting there
running, so examples like AppleTalk is a server running
on our system, well, it's actually an add-on, it's its
own thread running inside the Net Server, and it gets
messages to send AppleTalk data, Appletalk headers and
such, then has a pointer to this BNetDevice that it
can send out packets with.
Now, we go on to reception, which
is slightly complicated. The kind of red boxes there
all represent things inside of the Net Server itself,
whereas the other colors represent add-ons to the Net
Server device drivers, things outside the Net Server.
So for the simple ethernet device it's pretty much the
same, but the arrow is going the opposite direction and
it goes up to this ether reader thread inside of Net
Server that will read the data, pass it off to deliver
packet, and the deliver packet function is a thing that
goes through and finds who is interested in this
packet, for IP, TCP/IP it will end up going to the Net
Server, who will strip off all the headers and such,
and finally deliver the data to the waiting
application.
For the nonethernet device, it's kind of similar at the bottom, but then you go through, you go through an extra step here, which is your packet handler -- when you get the nonethernet packet, you can't hand it off to deliver a packet quite yet. Let me think about that.
Well, anyway, I think you can, I think --
I don't know why that box is there, it's a little
confusing, but when you get the packet you can hand it
off to deliver packet and when it goes through the
protocols you will come across your own packet handler
that you can use to then pass it off to a Net Server if
it's an IP packet, I mean it possibly may go off to a
non-IP protocol, also. And yeah, that's what that
yellow box is, that could be AppleTalk, whatever, it
has its own way of delivering data back to an
application. Hopefully these diagrams will clear
things up.
All right. So then the time-outs are
very useful for doing a lot of networking stuff, so
there is very simple API here for doing them. If you
are interested in a time out, you need to implement the
BTimeOutHandler API, you can set a time out where you
give a pointer to that object that's going to be called
back with timed out, and you give a time, a time of how
long in the future you want that time out to occur,
just a one-shot time out that's given in milliseconds,
actually rather than microseconds, so one of two things
will happen after you do a set time out, either the
packet, you know, an acknowledged packet comes in or
something you are not interested anymore in having the
time out occur, in which case you can cancel it with
this receipt that you got from set time out, or the
acknowledgement doesn't come back in, in which case
your timed out method will be called and you can do
whatever you can do.
All right. So that's the end of this. I
think the C++ API will make things pretty simple for a
lot of the things you need to do. As far as doing
configuration and all that stuff, I have done a little
bit of stuff on Windows with drivers and it's a real
pain in the butt, the configuration part, so it's a lot
simpler this way. Of course Unix is, you know, meant
for people that know what they are doing anyway, so
they often punt on that whole configuration part.
So the kernel driver, if you have already have a driver you are porting, that part may not be that hard so you can pretty much do what you want there. But, anyway, it can be hard. And finally, I just want to let you know a lot of the stuff is really hard to do unless you have sample source. We have some real device drivers that we will probably ship, I shouldn't say probably, we definitely will make a source available to one of the, probably the DEC PCI driver, we will make available fairly soon.
I'm going to stop here and take questions. Any questions? Go ahead.
A SPEAKER: The PCI driver you just spoke of, what type of cards --
BRAD TAYLOR: It's the 10 megabit 21040/21041, it's very similar to the fast ethernet one, the 21140, so it shouldn't be that hard to modify that driver. I looked at it a little bit myself but I have had other priorities so I haven't had a chance to finish that. I don't know if I will have time in the future, so go ahead and work on it if you want to.
A SPEAKER: Question about efficiency and speed. How many layers can you saturate?
BRAD TAYLOR: How many?
A SPEAKER: How much ethernet can you saturate?
BRAD TAYLOR: How many ethernet?
A SPEAKER: With multiple ethernet cards in the box can you saturate all of them? How many can you saturate?
BRAD TAYLOR: I --
A SPEAKER: How do you --
BRAD TAYLOR: I can tell you that the Net Server is all multithreaded, so that won't be a bottleneck. It's not something I've measured, I don't even know if, you know, it's not something I've measured, so I don't know the answer to that. I don't see any bottlenecks in saturating all of them, other than traditional ones, CPU and memory things, but as far as the architecture of the Net Server itself, it shouldn't prevent that.
A SPEAKER: Are you doing anything with gigabit ethernet?
BRAD TAYLOR: The answer is no. Our drivers are currently the onboard PowerMac ethernet, this DEC 10 megabit card, the ISA, based NE 2000 clone cards, which obviously only work on BeBox, and the 3Com Etherlink II card, and time permitting we will add more, but like I say, I'm very time strapped, there are other things I'm working on for TCP performance and such, so I really need third parties to write these drivers.
Yes?
A SPEAKER: What about IPV6?
BRAD TAYLOR: What's the question?
A SPEAKER: What --
BRAD TAYLOR: We don't implement it. Do you want to know when we are going to implement?
A SPEAKER: All the stuff I saw on the slide had 32 bit ints coming back from IP addresses and stuff.
BRAD TAYLOR: Right.
A SPEAKER: So that's going to mean basically treating IPBV6 as a separate network call, right?
BRAD TAYLOR: It is a separate protocol, so that's how that will be done, we have an IP device, on IPV6 you will have an IPV6 device and you pass the IPV6 address. The ethernet stuff won't change, that's all the same.
A SPEAKER: Right. I didn't see the beginnings of the talk, but are you saying that there is a different path through that Net Server for IP and non-IP?
BRAD TAYLOR: Yes, let me go back to the picture. You know, I went a little too fast there.
A SPEAKER: So IP is special case inside the Net Server, is what you are telling us.
BRAD TAYLOR: That's right. This yellow box would be an example of an alternative protocol. If you want an IPV6, that's what it would be, it would be an add-on to the Net Server, the sockets themselves that we have right now, a lot of things don't deal with IPV6, you have to deal with your own IPV6 applications and everything, that's how we do AppleTalk, we have our own little sockets for AppleTalk, that talk to the AppleTalk add-on, they all go through the standard socket mechanism.
Anybody over here? Go ahead.
A SPEAKER: I have two questions. One is promiscuous support.
BRAD TAYLOR: It's not in there, when I was looking through my slides yesterday I thought gee, you should really have promiscuous, especially if you want to do a packet sniffer. That's probably going to be added for the final DR9.
A SPEAKER: One thing there for transmit, the driver shouldn't be -- there should be a special transmit for the ethernet driver will not plug in the source address, because the promiscuous application would, for example, simulate the network traffic where it wants to send out packets that have a different source address.
BRAD TAYLOR: Right. For the write function on the ethernet driver or the send packet is, I mean I don't know if I understand your question, but you can put in there whatever you want. It's just -- it just treats it as data.
A SPEAKER: Normally ethernet drivers plug in the source address because the other protocols don't care about it.
BRAD TAYLOR: Well, you don't have to do it, the higher level the Net Server puts in the source.
A SPEAKER: The second question is, can you define the Net Server a little more in that what exactly is inside Net Server and what are its interface and is that on the web?
BRAD TAYLOR: Is that what?
A SPEAKER: On the web site.
BRAD TAYLOR: No, I don't think we have that. In some respects it looks like, you know, like a traditional IP or protocol stack, so we have, you know, you can kind of get a picture of it from here, at the top you have a socket interface, you know, from applications and some little, it's a private message communication thing between the socket and the Net Server itself, so basically just a way to get what was in the socket call up to the Net Server. At that point it's a matter of let's say it's TCP, it goes down the next level of stack TCP, sends this data, TCP has a hook into IP, below that, below that you have your ethernet drivers. It's just -- I can draw a picture for you, but it's --
A SPEAKER: Is it essentially TCP/IP, is that what it is?
BRAD TAYLOR: It has, UDP in there, but that's all, anything outside of TCP/IP and UDP and ethernet, you know, is done as an add-on to the Net Server. It doesn't know about anything other than those things I mentioned. And things like related things like ARP and, it does know about. AppleTalk, IPV6, anything like that has to be done as an add-on.
A SPEAKER: How do you handle power management?
BRAD TAYLOR: How do I handle power management? Well, I don't. Anything in particular that you think needs to be done?
A SPEAKER: I mean, how would you tell it the driver reacts, so if you are loading a power --
BRAD TAYLOR: We don't do power management in Be in general. So I suppose that that issue will be resolved when that's figured out for all the other drivers, how ethernet drivers do that. I think that will end up being your own, outside the scope of this, the Net Server doesn't care about power management but perhaps the kernel does, and the kernel will talk to your device driver.
A SPEAKER: Is that I/O control for power --
BRAD TAYLOR: Something like that. It doesn't exist but it will in the future.
Go ahead.
A SPEAKER: On your support for the DEC fast ethernet chip, is that for anything based on the reference design, any maker, or is that just a particular maker?
BRAD TAYLOR: I guess I got my hands on a couple of Znyx cards? And so I just started playing around. Z-n-y-x, something like that. I just started playing around, I learned that, yeah, they all seem to be different, can you really write a generic driver? It doesn't seem possible. So yeah, the support in there was just for that card but it's nowhere near complete.
A SPEAKER: Only DEC's card itself?
BRAD TAYLOR: Well, the card I said was Z-y-n-x, Zynx card, and/or Zynx, I don't know how you say that. Yes, it wasn't DEC's card, but it's DEC's chip, but they screw it up a little bit.
A SPEAKER: Is it all going to be a little bit different?
BRAD TAYLOR: As far as I can tell they all seem to be a little bit different. Unlike the 21040 or 21041, I don't know if it's possible. You guys are more expert at this than I am.
A SPEAKER: Can we stack protocols?
BRAD TAYLOR: No, it's not stackable. It's sort of, you have two levels that you can get in at, you can be -- you can come in below IP or you can come in above the device, ethernet device or ATM or whatever, but for getting in between there there is no API to do that.
A SPEAKER: So basically you are saying if you want to do an encryption type thing, there is no place to plug that in.
BRAD TAYLOR: Well, you could, I mean if you talk about --
A SPEAKER: Where would you put it?
BRAD TAYLOR: If you did a packet sniffer type thing, a higher priority you get the ethernet packet, I suppose you could encrypt it and then say okay, I wasn't interested in this packet and it goes on to the next guy and gets an encrypted packet. I don't know if that satisfies your needs or not. But that might work.
A SPEAKER: Which AppleTalk protocols have you written?
BRAD TAYLOR: Okay, so we have, the support in DR9 is only to do printing. So.
A SPEAKER: PAP.
BRAD TAYLOR: It has PAP, it has DDP, and it has NBP.
A SPEAKER: CHAP?
BRAD TAYLOR: Actually the hooks into those are not official. All right? They are not even documented. So the purpose of doing DR9 was just to get printing working, not to give developers access to the AppleTalk protocol itself. We will look at that later.
A SPEAKER: What if we want to link into the AppleShare server?
BRAD TAYLOR: Right. You know, you can work around -- you can get your own AppleTalk stack and not use Be's. If you can do such a thing, then that will work.
A SPEAKER: Can you replace Be's AppleTalk stack with your own?
BRAD TAYLOR: Yes. All the Net Server does is go through, in that Net Settings thing there is a thing called protocols, and it has a list of protocols that it should add on. Let me go back to this here, it's kind of ad hoc right now, this click enables AppleTalk here, all that does is it pass the word AppleTalk as the protocol it's supposed to add on. But you know, if you wanted to put in our own AppleTalk into that list it wouldn't be enabled by this button anymore, it would gladly load it and start it running.
A SPEAKER: Are we going --
BRAD TAYLOR: In back there.
A SPEAKER: Are you going to have support for Open Transport? I heard it's available.
BRAD TAYLOR: Whoa. Does anyone really care about the answer to that question? Okay. I didn't think so.
A SPEAKER: Did you provide an API for --
BRAD TAYLOR: I didn't hear it. Can you say it louder?
A SPEAKER: Did you provide an API for session management for point to point?
BRAD TAYLOR: What kind of session management did you have in mind?
A SPEAKER: Well, the session registering sessions.
BRAD TAYLOR: I don't know if I understand.
A SPEAKER: Your PPP.
BRAD TAYLOR: Right, PPP.
A SPEAKER: Do you have to dial in an ID number or whatever to get authentication, is that API --
BRAD TAYLOR: No. Okay. So there is no API for doing that. Do we have these IP devices? I can show you the picture again. PPP is implemented, as a BIpDevice, so the Net Server simply gives an IP address and a packet and says send this packet. So what we do, PPP itself, may have -- looks at configurations and see what phone number and everything was configured, looks that up and dials the number and starts doing the PPP negotiation, the guy says I want to do PAP, in this case it's password authentication protocol, and it throws up dialogues and asks you to type it in. All that stuff is sort of hidden from the Net Server, it doesn't have to know about any of that. I don't know if I answered your question or not.
A SPEAKER: Well, I was just asking if you had an API that would generalize your version of the device itself?
BRAD TAYLOR: Would generalize the what?
A SPEAKER: The configuration of the PPP.
BRAD TAYLOR: That was the Be -- let me go back to that slide.
This config here? This config method, it's completely open to anything you want to do because all you do is you are handed a pointer for the Net Settings and you pass a pointer back to the Net Server and you can do whatever you want. You can configure out to your heart's delight. When you are done you call the callback on the Net Server to get your settings, it may save them for you, it may not. Depending on what you want to do.
A SPEAKER: The DR8 server didn't have routing support. Or didn't seem to work if it did have. Could we have routing support inside -- can you connect to a web server on your machine from your own machine now?
BRAD TAYLOR: I think you are going to be able to do that in the final DR9, there is a bug in the limitation in the CD that you have right now, where you can connect by the loopback port.
A SPEAKER: Right, but you have to specify the loopback.
BRAD TAYLOR: Right. That's a bug and that will be fixed. So. Right?
A SPEAKER: Suppose you write a protocol stack such AppleShare or something like that, are the mechanisms and APIs defined to move the file system to that parallel protocol stack so you could have icons show up on the desktop for the external file system or be able to switch in the protocol stacks?
BRAD TAYLOR: Well, we do. The way that the file system was done in DR9 is that we added a file system switch, if you are familiar with that Unix concept, but I guess in the Windows world we have to call it a redirector. But we have the ability to add on your own file systems, again it's one of those things where here is the things you implement in your own file system, what you do, you know, beyond that is your own business. If you want to go over, you know, an AppleTalk and AppleShare, go do that. So that's how that would be done. It doesn't involve the Net Server at all, it's really more of a file system add-on issue to do that kind of thing. I mean it involves in the end yes, you have to send AppleTalk packets, but the Net Server is not involved with anything in the file system.
A SPEAKER: Brad? Will a network device driver written for DR9 be binary compatible with future versions of the OS?
BRAD TAYLOR: That's the idea. I mean DR9 in general, the idea is that this our binary compatible release, that when you write things for DR9, and we will support them, you know, from some end releases in the future, right now it's not too big, I don't know about 10, but probably at least 2 will support it. The way I have done most of the API it should be fairly easy to support binary compatibility. The harder problem is more when you have shared libraries that contain C++ that becomes harder and most of the stuff here doesn't involve that, so. I don't see any problem with it. Well, there is one thing that may happen in the future that could change all this, but I think we would still make the binary compatibility, it's more a performance thing. At some point the TCP code may be moved into the kernel. I'm not working on that right now, but at some point we may decide the only way to get good performance out of whatever might be gigabit ethernet to move the code into the kernel, in which case a lot of this stuff will change. It may still be C++, but you can't go and throw up windows or things anymore. That's the only thing I know of that may sort of break things, I think we can still support the old drivers but they just run pretty slow.
Nobody else? All right. Thanks for coming.
(Applause.)
A SPEAKER: Actually I have a question.
BRAD TAYLOR: All right.
A SPEAKER: With Windows system, the graphics API in DR8 when you went to get a BWindowsScreen that service would clone a copy of the video drivers into your memory space, then the application itself was going direct to the video driver using the code that is in your memory map.
BRAD TAYLOR: Right.
A SPEAKER: Is there a similar sort of thing to be able to do more network drivers so that if say we have an application we want to implement a protocol stack in we don't want to talk to the Net Server at all, what we would like is a clone of the ethernet card driver in our space or something like that that we can talk to directly.
BRAD TAYLOR: What I would suggest, well, there is no way to do what you are saying. I think you get most of what you are saying by having simply an add-on to the Net Server doing most of the work or whatever it is you needed done. And using perhaps shared memory or something to communicate that information to the other applications.
A SPEAKER: It seems more like an issue if you are going to move IP into the kernel, then I guess are you going to have a -- do you have an API for the kernel IP talking to the device driver or is the kernel going to have to open up the kernel driver to talk to the ethernet hardware and anybody who wants to -- I guess what I'm asking for is will we have multiple opens in the ethernet driver?
BRAD TAYLOR: No, the ethernet driver should only be open once. Anything else is handled outside of that.
A SPEAKER: I guess my question involves this, pertains to supporting for network games.
BRAD TAYLOR: Right. Well, yeah, I mean getting direct access on every card doesn't really make as much sense as it does to video hardware because if you take something like TCP, which most people like to use for communicating, you can't implement your own TCP, you can but it's probably a lot more work than you want to do. It's not going to be much faster than what we're doing, what we provide at all. Then there is UDP, and UDP is only a thin veneer on top of ethernet and IP, so that's what I would recommend trying first, before you decide gee, I really have to have direct access, try using UDP and see if that does the job, and if not maybe you can add it to the Net Server where you can get more direct access to the network driver. The network is such that you don't really want too many people getting access to the same piece of critical memory, it's going to mess things up. If it's video, it's like oh, so what, if it's messy once in awhile, it's just a game. But if it's networking, it could really mess something important up.
A SPEAKER: Say net files or something, and you didn't intend to export that service to the machine in general, or something like that, but for the most part you are dumping it in.
BRAD TAYLOR: Any more questions? Last question. Okay, I've got five more minutes.
A SPEAKER: The DR9 driver for networking, is it intended that will support processor agnostic driver development? Or is it primarily just for PowerPC drivers?
BRAD TAYLOR: API?
A SPEAKER: Yes.
BRAD TAYLOR: I didn't see any references to PowerPC in the API, so I don't see any reason why that won't just, you know, be a recompile. The one thing probably is, you know, I have to make clear like that address that's passed to send packet for an IP device, what byte order is that in? I'll tell you right now, it's big-endian, so if you are worried about that kind of thing, you know, for a recompile to a little-endian architecture, then you should you make sure that gets the whole big-endian value. Other than that I really don't see any problems.
All right. I think that's all the questions. All right. Thanks.
(Applause.)
Home | About Be | Be Products | BeWare | Purchase | Events | Developers | Be User Groups | Support