hello I picked up the cd at comdex and was wondering
is there planned / actual support for usb nic yet?
if so is the netgear ea101 on the hcl?
also if usb nics are suppored which ones?
thanks
Wuss912 <Wuss912@home.com> wrote:
hello I picked up the cd at comdex and was wondering
is there planned / actual support for usb nic yet?
Yes, we are planning to have usb nic support but have not released any
drivers yet. Not sure which ones we will be supporting…
Initial usb support will be for mice, keyboards and printers.
Chris
if so is the netgear ea101 on the hcl?
also if usb nics are suppored which ones?
thanks
“Chris Travis” <ctravis@qnx.com> wrote in message
news:8vuk7k$ib3$1@nntp.qnx.com…
Wuss912 <> Wuss912@home.com> > wrote:
hello I picked up the cd at comdex and was wondering
is there planned / actual support for usb nic yet?Yes, we are planning to have usb nic support but have not released any
drivers yet. Not sure which ones we will be supporting…
Initial usb support will be for mice, keyboards and printers.
Crikey ! I’m no USB guru, but I thought that a communication device
class driver would be a sufficient abstraction to support all ethernet
adapters. Doesn’t this mean that you would “only” need to write a
communication class driver with ethernet functionality to support all
USB ethernet adapters ?
as best I can tell you need a diffrent driver for each chipset at least
in linux..
In article <903f8a$14k$1@inn.qnx.com>, john@csical.com says…
“Chris Travis” <> ctravis@qnx.com> > wrote in message
news:8vuk7k$ib3$> 1@nntp.qnx.com> …
Wuss912 <> Wuss912@home.com> > wrote:
hello I picked up the cd at comdex and was wondering
is there planned / actual support for usb nic yet?Yes, we are planning to have usb nic support but have not released any
drivers yet. Not sure which ones we will be supporting…
Initial usb support will be for mice, keyboards and printers.Crikey ! I’m no USB guru, but I thought that a communication device
class driver would be a sufficient abstraction to support all ethernet
adapters. Doesn’t this mean that you would “only” need to write a
communication class driver with ethernet functionality to support all
USB ethernet adapters ?
\
I’m not doubting you wrt Linux, but it just doesn’t make a lot of
sense from a technical viewpoint. Once you can talk through the
USB controller, what possible h/w dependancies could there be
with a chip that is on the other side (i.e. the other side of the host
controller, and the device controller) ?
From everything I have read, there should be something like a
communication class driver that does practically everything, and
a very thin adaptation layer for a specific “instance” of
communication class device. If this is not the case, then what
the heck is the point of USB (same h/w dependencies as PCI
bus with greater latency, and a tiny fraction of the throughput -
this; just so end users don’t have to open the case - say it aint
so) ? Any implementation that doesn’t take advantage of the
hardware abstraction capabilities seems, well; icky…
Maybe it does work as I hope, and I am just over-reacting to
the use of the term “driver” wrt a particular device instance
(i.e. if a “driver” is just a handful of “adaptation layer” lines of
code, then all is well). A “driver” (enabler would be a more
appropriate word) should be nothing more than a very small
“.so” that gets loaded by the USB resmgr in RtP, once it
enumerates the device.
“Wuss912” <Wuss912@home.com> wrote in message
news:MPG.1492216f8bc6a099989681@inn.qnx.com…
as best I can tell you need a diffrent driver for each chipset at least
in linux..
In article <903f8a$14k$> 1@inn.qnx.com> >, > john@csical.com > says…“Chris Travis” <> ctravis@qnx.com> > wrote in message
news:8vuk7k$ib3$> 1@nntp.qnx.com> …
Wuss912 <> Wuss912@home.com> > wrote:
hello I picked up the cd at comdex and was wondering
is there planned / actual support for usb nic yet?Yes, we are planning to have usb nic support but have not released any
drivers yet. Not sure which ones we will be supporting…
Initial usb support will be for mice, keyboards and printers.Crikey ! I’m no USB guru, but I thought that a communication device
class driver would be a sufficient abstraction to support all ethernet
adapters. Doesn’t this mean that you would “only” need to write a
communication class driver with ethernet functionality to support all
USB ethernet adapters ?
\
well in that case i think i got bad news for ya
the usb nics ive been playing with have to download their firmware from
the pc so it seems to be a little more than drivers
This isn’t necessarily bad news. The key is whether the mechanism
for downloading the firmware is standardized (in which case all that
needs to be done is copy the firmware image from the windows
drivers - this is not a problem).
“Wuss912” <Wuss912@home.com> wrote in message
news:MPG.149a3ba59e141274989682@inn.qnx.com…
well in that case i think i got bad news for ya
the usb nics ive been playing with have to download their firmware from
the pc so it seems to be a little more than drivers
Aren’t standards nice? Except when you have too many of them for the same
type of thing.
Using your logic, all PCI NICs should work exactly the same way, so you’d
only need one driver. But as we know, that’s definately not the case.
As another example, consider your typical “Hayes compatible” modem. How
many variations are there on that scheme? But it’s just serial, right? And
I’m not even counting the “WinModem” class of modems.
Give me a communications interface and I’ll give you a barrel of standards
for communicating across it.
“John Doe” <john@csical.com> wrote in message
news:915hj2$s8o$1@inn.qnx.com…
This isn’t necessarily bad news. The key is whether the mechanism
for downloading the firmware is standardized (in which case all that
needs to be done is copy the firmware image from the windows
drivers - this is not a problem).“Wuss912” <> Wuss912@home.com> > wrote in message
news:> MPG.149a3ba59e141274989682@inn.qnx.com> …
well in that case i think i got bad news for ya
the usb nics ive been playing with have to download their firmware from
the pc so it seems to be a little more than drivers