3C589C/589D in RTP?

Hello,

I am confused. In QNX4 these chipsets: 3C589C/589D are supported, in RTP
no. Why not?
If you have already drivers made for QNX4 why don’t you use them for
RTP? The porting should not be a problem.

these are PCMCIA ethernet cards from 3com.
Stefan

“Stefan Parvu” <sparvu@cc.hut.fi> wrote in message
news:39FE733B.7E02859B@cc.hut.fi

Hello,

I am confused. In QNX4 these chipsets: 3C589C/589D are supported, in RTP
no. Why not?
If you have already drivers made for QNX4 why don’t you use them for
RTP?



The porting should not be a problem.

QNX4 and RTP network driver are completely different, they
required almost a complete rewrite.

these are PCMCIA ethernet cards from 3com.
Stefan

Really ? even if RTP and QNX4 are different OS (libs are differents)
which is bad … the drivers should not differ so much. You can define
an abstract DDK for them and you should be able at leat 30%, or 40% to
keep the compatibility.

100% rewrite means loosing money and time … This is bad!!!

Really bad!
stefan


Mario Charest wrote:

“Stefan Parvu” <> sparvu@cc.hut.fi> > wrote in message
news:> 39FE733B.7E02859B@cc.hut.fi> …
Hello,

I am confused. In QNX4 these chipsets: 3C589C/589D are supported, in RTP
no. Why not?
If you have already drivers made for QNX4 why don’t you use them for
RTP?

The porting should not be a problem.

QNX4 and RTP network driver are completely different, they
required almost a complete rewrite.

these are PCMCIA ethernet cards from 3com.
Stefan

Stefan Parvu <sparvu@cc.hut.fi> wrote:

Really ? even if RTP and QNX4 are different OS (libs are differents)
which is bad …

Why is it bad?

the drivers should not differ so much.

Why not?

You can define an abstract DDK for them and you should be able at leat
30%, or 40% to keep the compatibility.

My personal feeling is that a lot of `compatibility’ type thinking is penny
wise and pound foolish. It saves time on initial implementation (maybe) at
the expense of constantly struggling to maintain the compatibility even when
the hardware doesn’t work at all the same way anymore.

Once in a while, it’s appropriate to make a clean break.

100% rewrite means loosing money and time … This is bad!!!
Really bad!

That sounds like a knee jerk response to me.

A 100% rewrite to a new design that allows you to write a driver in three
days compared to a 20% rewrite to a design that requires thirty days to
write a driver for is not a loss of time or money.

If I still had to write video drivers using the standard VGA hardware
mechanisms, I’d go find another job.

for some reasons I can’t reply to this newsgroup in time … it takes a
while to send an email …

Pete,

I’ve got your idea.I didn’t want to hit your knee :slight_smile:

Anyway if you would think as an end user, not developer, then:

-QNX4 supports already 3C589C/589D. Good, make them as fast as you can
available for RTP

-The end user does not care about you have another OS based on different
libs so from end-user point of view RTP should be able already to run
3C589C/589D cards since you have knowledge to do that … You did
already in QNX4. Make them available. they can test and more they can
see if it is working.

-Why forcing users buying new hardware when the old stuff should first
be ported, rewrite to RTP.

-I said “really bad” in idea that QSSL will maybe provide some new
drivers after some months, so 100% changes in DDK or kernels would
produce a delay as well in hole mechanism of your business belive me.
Maybe I am wrong here but usually in UNIX world is like this.

-On the other hand you should provide a compatibility between OSes
anyway. this is what I learned in my school. Otherwise you are writing
the same stuff with another parfume …

So, I am an end user now, and I have some old cards 3C589C/589D which I
can’t run. QNX4 can do it.
RTP not. That’s was my point: buy a new piece of hardware cause they are
not ported to RTP.
Anyway from my point of view if you have some stuff working for QNX4
then it should be nice to have for RTP as well.

stefan


pete@qnx.com wrote:

Stefan Parvu <> sparvu@cc.hut.fi> > wrote:
Really ? even if RTP and QNX4 are different OS (libs are differents)
which is bad …

Why is it bad?

the drivers should not differ so much.

Why not?

You can define an abstract DDK for them and you should be able at leat
30%, or 40% to keep the compatibility.

My personal feeling is that a lot of `compatibility’ type thinking is penny
wise and pound foolish. It saves time on initial implementation (maybe) at
the expense of constantly struggling to maintain the compatibility even when
the hardware doesn’t work at all the same way anymore.

Once in a while, it’s appropriate to make a clean break.

100% rewrite means loosing money and time … This is bad!!!
Really bad!

That sounds like a knee jerk response to me.

A 100% rewrite to a new design that allows you to write a driver in three
days compared to a 20% rewrite to a design that requires thirty days to
write a driver for is not a loss of time or money.

If I still had to write video drivers using the standard VGA hardware
mechanisms, I’d go find another job.

Stefan Parvu <sparvu@cc.hut.fi> wrote:

for some reasons I can’t reply to this newsgroup in time … it takes a
while to send an email …

Anyway if you would think as an end user, not developer, then:

-QNX4 supports already 3C589C/589D. Good, make them as fast as you can
available for RTP

-The end user does not care about you have another OS based on different
libs so from end-user point of view RTP should be able already to run
3C589C/589D cards since you have knowledge to do that … You did
already in QNX4. Make them available. they can test and more they can
see if it is working.

It is not a goal of RTP to support all the hardware that was ever supported
under QNX4.

-Why forcing users buying new hardware when the old stuff should first
be ported, rewrite to RTP.

Take the money you saved by not having to purchase the OS and buy hardware
that is supported, or wait until we have had time to support your hardware,
or wait until there are development kits for everything and support it
yourself.

-I said “really bad” in idea that QSSL will maybe provide some new
drivers after some months, so 100% changes in DDK or kernels would
produce a delay as well in hole mechanism of your business belive me.
Maybe I am wrong here but usually in UNIX world is like this.

I don’t understand what you’re saying. I am not saying that there will
never be a driver for your card… I am trying to correct the misperception
you have that redesigning things is always bad.

-On the other hand you should provide a compatibility between OSes
anyway. this is what I learned in my school. Otherwise you are writing
the same stuff with another parfume …

Most of the stuff I learned in school is theory. Most of the stuff I’ve
learned since is reality.

So, I am an end user now, and I have some old cards 3C589C/589D which I
can’t run. QNX4 can do it.
RTP not. That’s was my point: buy a new piece of hardware cause they are
not ported to RTP.
Anyway from my point of view if you have some stuff working for QNX4
then it should be nice to have for RTP as well.

I can see your point. It would be great if instead of you having to spend a
few tens of dollars on a supported network card, we spent a few tens of
thousands paying someone to port it.

Yes Pete that would be nice, and hope when DDK materials will be out I
could think to look how to write a driver for RTP. I think there will be
as well some examples. Now I think it is time for home.

See you guys tomorrow. Here is 8:20pm Tue. BTW another Boeing 747-400
crashed. In Taipei I think.
stef

pete@qnx.com wrote:

Stefan Parvu <> sparvu@cc.hut.fi> > wrote:
for some reasons I can’t reply to this newsgroup in time … it takes a
while to send an email …

Anyway if you would think as an end user, not developer, then:

-QNX4 supports already 3C589C/589D. Good, make them as fast as you can
available for RTP

-The end user does not care about you have another OS based on different
libs so from end-user point of view RTP should be able already to run
3C589C/589D cards since you have knowledge to do that … You did
already in QNX4. Make them available. they can test and more they can
see if it is working.

It is not a goal of RTP to support all the hardware that was ever supported
under QNX4.

-Why forcing users buying new hardware when the old stuff should first
be ported, rewrite to RTP.

Take the money you saved by not having to purchase the OS and buy hardware
that is supported, or wait until we have had time to support your hardware,
or wait until there are development kits for everything and support it
yourself.

-I said “really bad” in idea that QSSL will maybe provide some new
drivers after some months, so 100% changes in DDK or kernels would
produce a delay as well in hole mechanism of your business belive me.
Maybe I am wrong here but usually in UNIX world is like this.

I don’t understand what you’re saying. I am not saying that there will
never be a driver for your card… I am trying to correct the misperception
you have that redesigning things is always bad.

-On the other hand you should provide a compatibility between OSes
anyway. this is what I learned in my school. Otherwise you are writing
the same stuff with another parfume …

Most of the stuff I learned in school is theory. Most of the stuff I’ve
learned since is reality.

So, I am an end user now, and I have some old cards 3C589C/589D which I
can’t run. QNX4 can do it.
RTP not. That’s was my point: buy a new piece of hardware cause they are
not ported to RTP.
Anyway from my point of view if you have some stuff working for QNX4
then it should be nice to have for RTP as well.

I can see your point. It would be great if instead of you having to spend a
few tens of dollars on a supported network card, we spent a few tens of
thousands paying someone to port it.

“Stefan Parvu” <sparvu@cc.hut.fi> wrote in message
news:39FF0C03.68A1E81@cc.hut.fi

Yes Pete that would be nice, and hope when DDK materials will be out I
could think to look how to write a driver for RTP. I think there will be
as well some examples. Now I think it is time for home.

If you’d seen both QNX4 network driver architecure and Neutrino 2.1
architecture you’d be glad they rewrote the hole thing :wink:

See you guys tomorrow. Here is 8:20pm Tue. BTW another Boeing 747-400
crashed. In Taipei I think.
stef

pete@qnx.com > wrote:

Stefan Parvu <> sparvu@cc.hut.fi> > wrote:
for some reasons I can’t reply to this newsgroup in time … it takes
a
while to send an email …

Anyway if you would think as an end user, not developer, then:

-QNX4 supports already 3C589C/589D. Good, make them as fast as you can
available for RTP

-The end user does not care about you have another OS based on
different
libs so from end-user point of view RTP should be able already to run
3C589C/589D cards since you have knowledge to do that … You did
already in QNX4. Make them available. they can test and more they can
see if it is working.

It is not a goal of RTP to support all the hardware that was ever
supported
under QNX4.

-Why forcing users buying new hardware when the old stuff should first
be ported, rewrite to RTP.

Take the money you saved by not having to purchase the OS and buy
hardware
that is supported, or wait until we have had time to support your
hardware,
or wait until there are development kits for everything and support it
yourself.

-I said “really bad” in idea that QSSL will maybe provide some new
drivers after some months, so 100% changes in DDK or kernels would
produce a delay as well in hole mechanism of your business belive me.
Maybe I am wrong here but usually in UNIX world is like this.

I don’t understand what you’re saying. I am not saying that there will
never be a driver for your card… I am trying to correct the
misperception
you have that redesigning things is always bad.

-On the other hand you should provide a compatibility between OSes
anyway. this is what I learned in my school. Otherwise you are writing
the same stuff with another parfume …

Most of the stuff I learned in school is theory. Most of the stuff I’ve
learned since is reality.

So, I am an end user now, and I have some old cards 3C589C/589D which
I
can’t run. QNX4 can do it.
RTP not. That’s was my point: buy a new piece of hardware cause they
are
not ported to RTP.
Anyway from my point of view if you have some stuff working for QNX4
then it should be nice to have for RTP as well.

I can see your point. It would be great if instead of you having to
spend a
few tens of dollars on a supported network card, we spent a few tens of
thousands paying someone to port it.

Most of the stuff I learned in school is theory. Most of the stuff I’ve
learned since is reality.

Kids, license to this; words of the wise.

I have the same complaint with video drivers not being backwards compatable
in comparison to QNX4

Consumers demand not to spend money on hardware evry time there is an
upgrade,
Whats more consumers sensably do not want to through out their hard earned
dollars in perfectly good hardware devices that are not damaged.

And intergrating honesty combined with scientific facts?
Spending tens of thousands of dollars porting a driver is
probably cheaper then spending tens of dollars times thousands of people
[us] in acuallity the porting is the cheaper way to go;

  • Providing the consumer is paying cash for the software!! Here we are
    NOT!!*


    However; I get a kick out of it when a software developers ego gets crushed
    and he jumps up and calls these potential customers of the
    future “Wishfull thinkers”, “unreasonable”, “demanding” and in some cases
    [not hear yet] “ignorant”.
    All that can result from this kind of flaming is a discouraged customer and
    a starving developer, we all loose.

Never the less we the experimenters do have to have a heart and realize
that we are indulging in a “hobbie” and like all hobbies they cost money,
I have resigned to the fact if I whant to play games I have to pay
once in a while.
Beta testing software is a passtime and or a game, get used to paying for
it and try not to bash the developers.
Screwing around with computers cost money, get used to it.

Slap, Slap, Slap , Wack, Wack ,wack gets us no where.
Personally if this was easy I would get board and drop the whole thing !!!