Native QNX4 or 6 SCSI Generic driver?

QNX Newsgroups (Archives) qdn.public.porting
1

Is there anyone who has looked at at doing a native low level generic
device driver for SCSI boards (SCSI Generic) . This is a character
device which would give access to CD burners and scanners – I’m
getting really annoyed at rebooting every time I want to use my
scanner.

I know the Fsys scsis drivers access the various cards as block
devices and that what I’m looking for would probably collide with
the provided Fsys drivers – but in my system the only thing on my
scsci card is the scanner so I’m (personally) willing to do a one or
the other type arrangement…

The SG library adds a device to the dev directory and then provides
char based IO and a set of IOCTL’s for the device. Basically this
implements the low level SCSI commands. Once an equivalent for SG was
ported, we would be able to use Linux packages such as SANE for the
scanner and (it is implied) the cd burner utilities…

This truly looks like a “how bad do you want it” situation but at the
moment I’m at least entertaining the development of a native
version (for the card in my system - an AHA-2930).

Anyone?

QNX - please tell me if this a “bad idea” ™ or more importantly, if
there is a way to do this built into the aha* drivers already…

-Bill

2

“William M. Derby Jr.” wrote:

Is there anyone who has looked at at doing a native low level generic
device driver for SCSI boards (SCSI Generic) . This is a character
device which would give access to CD burners and scanners – I’m
getting really annoyed at rebooting every time I want to use my
scanner.

I know the Fsys scsis drivers access the various cards as block
devices and that what I’m looking for would probably collide with
the provided Fsys drivers – but in my system the only thing on my
scsci card is the scanner so I’m (personally) willing to do a one or
the other type arrangement…

The SG library adds a device to the dev directory and then provides
char based IO and a set of IOCTL’s for the device. Basically this
implements the low level SCSI commands. Once an equivalent for SG was
ported, we would be able to use Linux packages such as SANE for the
scanner and (it is implied) the cd burner utilities…

This truly looks like a “how bad do you want it” situation but at the
moment I’m at least entertaining the development of a native
version (for the card in my system - an AHA-2930).

Anyone?

QNX - please tell me if this a “bad idea” ™ or more importantly, if
there is a way to do this built into the aha* drivers already…

QSSL, I’d also like to know if current drivers/ioctl’s can do this. I’m
working with an open source project trying to get software called
“cdrecord” to work on QNX4.


-Bill

3

Dean Douthat wrote:

“William M. Derby Jr.” wrote:

Is there anyone who has looked at at doing a native low level generic
device driver for SCSI boards (SCSI Generic) . This is a character
device which would give access to CD burners and scanners – I’m
getting really annoyed at rebooting every time I want to use my
scanner.

I know the Fsys scsis drivers access the various cards as block
devices and that what I’m looking for would probably collide with
the provided Fsys drivers – but in my system the only thing on my
scsci card is the scanner so I’m (personally) willing to do a one or
the other type arrangement…

The SG library adds a device to the dev directory and then provides
char based IO and a set of IOCTL’s for the device. Basically this
implements the low level SCSI commands. Once an equivalent for SG was
ported, we would be able to use Linux packages such as SANE for the
scanner and (it is implied) the cd burner utilities…

This truly looks like a “how bad do you want it” situation but at the
moment I’m at least entertaining the development of a native
version (for the card in my system - an AHA-2930).

Anyone?

QNX - please tell me if this a “bad idea” ™ or more importantly, if
there is a way to do this built into the aha* drivers already…

QSSL, I’d also like to know if current drivers/ioctl’s can do this. I’m
working with an open source project trying to get software called
“cdrecord” to work on QNX4.

I’m not QSSL, but for what it’s worth, here is what I know…
It is possible to get cdrecord working with current drivers, but it
would be very awkward thing to do. You’d have to use low level SCSI
commands via PASS THROUGH mechanism. For scanners it is even worse since
there’s no device for it (it is possible to solve that too, but in even
more awkward way).

The result would be very fragile and dangerous code. Since it would be
doing things under the feet of filesystem driver, you can easily damage
your filesystem due to a bug, so it would be safe to use only if no hard
drives are present on the bus.

For better solution you have to wait until devb drivers’ architecture
gets out of ‘flux’ state. The current ‘flux’ is related to the fact that
QSSL wants to support CAM (a-la FreeBSD). For those who don’t know, CAM
is Unix equivalent of ASPI in Windows. When they do, it’d be really
straightforward task to support all kind of SCSI devices.

Bad news is, it has been promiced about a year ago and still did not
happen ;(

  • Igor
4

Igor Kovalenko wrote:

Dean Douthat wrote:

[ clip … ]

For better solution you have to wait until devb drivers’ architecture
gets out of ‘flux’ state. The current ‘flux’ is related to the fact that
QSSL wants to support CAM (a-la FreeBSD). For those who don’t know, CAM
is Unix equivalent of ASPI in Windows. When they do, it’d be really
straightforward task to support all kind of SCSI devices.

Today it is in ‘flux’ because of that ASPI … tomorrow it will be
in flux for any other reasons. Will we ever see sources?

Bad news is, it has been promiced about a year ago and still did not
happen ;(

Not only that … QNX 4 provides much more ‘open sources’ than QNX
6.

QNX4 QNX6
serial driver yes NO!
parall. driver yes NO!
floppy driver yes NO!
disk driver yes NO!
DAQ driver yes NO!
a.s.o …

How can QSSL call QNX 6 (aka QNX RTP) an ‘open source’ OS ???

Armin

You can fool all people some of the time,
and some of the people all of the time,
but you cannot fool all the people all the time.
[Abraham Lincoln, 1858]






\

  • Igor
5

On Mon, 19 Feb 2001 12:42:25 -0600, Igor Kovalenko
<Igor.Kovalenko@motorola.com> wrote:

I’m not QSSL, but for what it’s worth, here is what I know…
It is possible to get cdrecord working with current drivers, but it
would be very awkward thing to do. You’d have to use low level SCSI
commands via PASS THROUGH mechanism. For scanners it is even worse since
there’s no device for it (it is possible to solve that too, but in even
more awkward way).

The result would be very fragile and dangerous code. Since it would be
doing things under the feet of filesystem driver, you can easily damage
your filesystem due to a bug, so it would be safe to use only if no hard
drives are present on the bus.

For better solution you have to wait until devb drivers’ architecture
gets out of ‘flux’ state. The current ‘flux’ is related to the fact that
QSSL wants to support CAM (a-la FreeBSD). For those who don’t know, CAM
is Unix equivalent of ASPI in Windows. When they do, it’d be really
straightforward task to support all kind of SCSI devices.

Bad news is, it has been promiced about a year ago and still did not
happen ;(

  • Igor

Thanks Igor,

Well I’ve been not been using my scanner on my QNX systems for 5
years now so I can wait a little while longer… I figured that using
the fsys drivers for this would be a potential disaster and thats why
I was leaning towards having a separate driver (and SCSI adaptor) for
the scanner… If we are talking more than a year out I might as well
try to do it myself… Of course I’m not likely to do more than get my
specific hardware working - after all (on the face of it) talking to a
scanner can’t be that bad given all the Linux stuff lying around…
hmmm…I may regret that statement - :wink:

QNX folks, what of the devb driver support? Also, what was the
rational for NOT supporting character mode devices in the standard
SCSI drivers… i.e. scanners, etc or at least a /dev/scsi_generic
which would allow a low level interface to the devices? It would seem
to me you have already implemented most of this functionality for the
disk drivers?

-Bill

6

“William M. Derby Jr.” wrote:

On Mon, 19 Feb 2001 12:42:25 -0600, Igor Kovalenko
Igor.Kovalenko@motorola.com> > wrote:

snip


Thanks Igor,

Well I’ve been not been using my scanner on my QNX systems for 5
years now so I can wait a little while longer… I figured that using
the fsys drivers for this would be a potential disaster and thats why
I was leaning towards having a separate driver (and SCSI adaptor) for
the scanner… If we are talking more than a year out I might as well
try to do it myself… Of course I’m not likely to do more than get my
specific hardware working - after all (on the face of it) talking to a
scanner can’t be that bad given all the Linux stuff lying around…
hmmm…I may regret that statement - > :wink:

QNX folks, what of the devb driver support? Also, what was the
rational for NOT supporting character mode devices in the standard
SCSI drivers… i.e. scanners, etc or at least a /dev/scsi_generic
which would allow a low level interface to the devices? It would seem
to me you have already implemented most of this functionality for the
disk drivers?

I don’t think there was any rationale. They have half-implemented CAM
layer and much of the rest of fsys subsystem appears to be a hack
quickly put together to provide something more or less working. I
suspect when Bill left to enjoy bike rides in the warmth of Florida
there was no one to really replace him. Then it was not long before John
left too, which did not help at all. There used to be common attitude of
neglect to disk subsystem in QSSL because their traditional markets
never demanded much in that area. No wonder nobody was interested in
developing that stuff.

You’re our last hope Brian :slight_smile:

  • igor
7

Armin Steinhoff wrote:

Not only that … QNX 4 provides much more ‘open sources’ than QNX
6.

QNX4 QNX6
serial driver yes NO!
parall. driver yes NO!
floppy driver yes NO!
disk driver yes NO!
DAQ driver yes NO!
a.s.o …

How can QSSL call QNX 6 (aka QNX RTP) an ‘open source’ OS ???

OTOH, QNX6 has much more open architecture. And it already has number of
DDKs released, which never ever happened with QNX4.

Speaking about sources, they have released their modified ALSA sources.
So far it did not lead to huge number of new drivers written by
volunteers. Sources are not enough, they are good to have as a reference
to understand something, but are only really useful when you have well
designed DDK.

  • igor
8

Igor Kovalenko wrote:

Armin Steinhoff wrote:

Not only that … QNX 4 provides much more ‘open sources’ than QNX
6.

QNX4 QNX6
serial driver yes NO!
parall. driver yes NO!
floppy driver yes NO!
disk driver yes NO!
DAQ driver yes NO!
a.s.o …

How can QSSL call QNX 6 (aka QNX RTP) an ‘open source’ OS ???


OTOH, QNX6 has much more open architecture.

That ‘openess’ is useless as long as it isn’t well documented.

And it already has number of
DDKs released, which never ever happened with QNX4.

Base of the DDKs are resource managers … which are also badly
documented.

For instance the iofunc_notify() call is not mentioned in the
resource manager doc … but
the documentation of the iofunc_notify() call refers to it.

Just a pointer into the void …

Speaking about sources, they have released their modified ALSA sources.

And they have it rewritten just to have a proprietary solution.
Do you believe you will see these sources any days??

So far it did not lead to huge number of new drivers written by
volunteers. Sources are not enough, they are good to have as a reference
to understand something,

That would us help to get rid of the dependancy of inconsistent
documentations.

but are only really useful when you have well
designed DDK.

The base of all of these DDKs is the resource manager library …
I’m very sceptic after seeing nano sleeps when I step thrue the
dispatch interface with GDB.


Armin

9

QSSL folks, any comment? Am I just whistling Dixie here?

Igor Kovalenko wrote:

Dean Douthat wrote:

“William M. Derby Jr.” wrote:

Is there anyone who has looked at at doing a native low level generic
device driver for SCSI boards (SCSI Generic) . This is a character
device which would give access to CD burners and scanners – I’m
getting really annoyed at rebooting every time I want to use my
scanner.

I know the Fsys scsis drivers access the various cards as block
devices and that what I’m looking for would probably collide with
the provided Fsys drivers – but in my system the only thing on my
scsci card is the scanner so I’m (personally) willing to do a one or
the other type arrangement…

The SG library adds a device to the dev directory and then provides
char based IO and a set of IOCTL’s for the device. Basically this
implements the low level SCSI commands. Once an equivalent for SG was
ported, we would be able to use Linux packages such as SANE for the
scanner and (it is implied) the cd burner utilities…

This truly looks like a “how bad do you want it” situation but at the
moment I’m at least entertaining the development of a native
version (for the card in my system - an AHA-2930).

Anyone?

QNX - please tell me if this a “bad idea” ™ or more importantly, if
there is a way to do this built into the aha* drivers already…

QSSL, I’d also like to know if current drivers/ioctl’s can do this. I’m
working with an open source project trying to get software called
“cdrecord” to work on QNX4.


I’m not QSSL, but for what it’s worth, here is what I know…
It is possible to get cdrecord working with current drivers, but it
would be very awkward thing to do. You’d have to use low level SCSI
commands via PASS THROUGH mechanism. For scanners it is even worse since
there’s no device for it (it is possible to solve that too, but in even
more awkward way).

The result would be very fragile and dangerous code. Since it would be
doing things under the feet of filesystem driver, you can easily damage
your filesystem due to a bug, so it would be safe to use only if no hard
drives are present on the bus.

For better solution you have to wait until devb drivers’ architecture
gets out of ‘flux’ state. The current ‘flux’ is related to the fact that
QSSL wants to support CAM (a-la FreeBSD). For those who don’t know, CAM
is Unix equivalent of ASPI in Windows. When they do, it’d be really
straightforward task to support all kind of SCSI devices.

Bad news is, it has been promiced about a year ago and still did not
happen ;(

  • Igor
10

Armin Steinhoff <A-Steinhoff@web_.de> wrote:

The base of all of these DDKs is the resource manager library …

Your ignorance is showing Armin…

11

William M. Derby Jr. <derbyw@derbtronics.com> wrote:

QNX - please tell me if this a “bad idea” ™ or more importantly, if
there is a way to do this built into the aha* drivers already…

This is a bad idea, and there is nothing built into the aha* drivers to
do this.

12

Dean Douthat <ddouthat@faac.com> wrote:

QSSL, I’d also like to know if current drivers/ioctl’s can do this.

No… the current drivers/ioctl’s can’t do this in a way that we would
recommend using.

13

pete@qnx.com wrote:

Armin Steinhoff <A-Steinhoff@web_.de> wrote:

The base of all of these DDKs is the resource manager library …

Your ignorance is showing Armin…

Drivers build on base of your DDKs are not resource managers?
Hmm … should we get rid of the resource library when we use the
DDKs?

Hope my ignorance is not as big as your ignorance against
documentation problems …
However … there is an ‘open’ QNX architecture … but it is
closed again by its own documentation!!

Open up that open architecture … and then we should talk about
‘open sources’ !!

Armin

14

On 20 Feb 2001 14:48:11 GMT, pete@qnx.com wrote:

William M. Derby Jr. <> derbyw@derbtronics.com> > wrote:

QNX - please tell me if this a “bad idea” ™ or more importantly, if
there is a way to do this built into the aha* drivers already…

This is a bad idea, and there is nothing built into the aha* drivers to
do this.

Thanks for your considered and illuminating response.

I take this to mean that if I want to use my scanner (ever) I will
need to write a driver myself…Or… Scanners are a bad idea and
should be stopped…

Bill

15

Why don’t you ‘open source’ one of your fieldbus drivers, Armin?
Then you sure will have moral authority to teach them open source
ways… :wink:

Armin Steinhoff wrote:

pete@qnx.com > wrote:

Armin Steinhoff <A-Steinhoff@web_.de> wrote:

The base of all of these DDKs is the resource manager library …

Your ignorance is showing Armin…

Drivers build on base of your DDKs are not resource managers?
Hmm … should we get rid of the resource library when we use the
DDKs?

Hope my ignorance is not as big as your ignorance against
documentation problems …
However … there is an ‘open’ QNX architecture … but it is
closed again by its own documentation!!

Open up that open architecture … and then we should talk about
‘open sources’ !!

Armin

16

William M. Derby Jr. <derbyw@derbtronics.com> wrote:

Thanks for your considered and illuminating response.

I take this to mean that if I want to use my scanner (ever) I will
need to write a driver myself…Or… Scanners are a bad idea and
should be stopped…

OK… you have taken it wrongly.

If you want to use your scanner now you will need to write a driver
yourself.

17

Igor Kovalenko wrote:

Why don’t you ‘open source’ one of your fieldbus drivers, Armin?

Igor, did I ever announce our product line DACHS becoming ‘open
source’?

Then you sure will have moral authority to teach them open source
ways… > :wink:

Moral authority?? Announcing ‘open source’, attracting the ‘Open
Source Community’ with promises, using open source applications for
their own purpose (e.g. gcc, gdb) … but not realizing the
promises to the ‘Open Source Community’.

What kind of moral is that ?

However … XFree86 is available for QNX Neutrino, file systems and
other system parts are portable … should the ‘Open Source
Community’ start a real open source project??

Armin

18

Armin Steinhoff wrote:

Igor Kovalenko wrote:

Why don’t you ‘open source’ one of your fieldbus drivers, Armin?

Igor, did I ever announce our product line DACHS becoming ‘open
source’?

No, you did not and that is exactly my point.

Then you sure will have moral authority to teach them open source
ways… > :wink:

Moral authority?? Announcing ‘open source’, attracting the ‘Open
Source Community’ with promises, using open source applications for
their own purpose (e.g. gcc, gdb) … but not realizing the
promises to the ‘Open Source Community’.

What kind of moral is that ?

Speaking about promices, yes you have your point. But note, you’re also
using open source applications for your own (commercial) purposes,
however you do not appear to be in hurry to embrace open source model in
your own business.

It is easy to criticize someone for ‘not realizing the promises to the
Open Source Community’. It is not so easy to show an example by
yourself. In my view, unless you’ve done yourself what you’re demanding
from others, you do not really have moral right to pour fountains of
harsh criticism on them.

However … XFree86 is available for QNX Neutrino, file systems and
other system parts are portable … should the ‘Open Source
Community’ start a real open source project??

Yes, indeed please start a real one. Make sure it is something
yours.

  • igor
19

“Igor Kovalenko” <Igor.Kovalenko@motorola.com> wrote in message
news:3A92D448.C618F974@motorola.com…

Armin Steinhoff wrote:

Igor Kovalenko wrote:

Why don’t you ‘open source’ one of your fieldbus drivers, Armin?

Igor, did I ever announce our product line DACHS becoming ‘open
source’?


No, you did not and that is exactly my point.

Then you sure will have moral authority to teach them open source
ways… > :wink:

Moral authority?? Announcing ‘open source’, attracting the ‘Open
Source Community’ with promises, using open source applications for
their own purpose (e.g. gcc, gdb) … but not realizing the
promises to the ‘Open Source Community’.

What kind of moral is that ?


Speaking about promices, yes you have your point. But note, you’re also
using open source applications for your own (commercial) purposes,
however you do not appear to be in hurry to embrace open source model in
your own business.

It is easy to criticize someone for ‘not realizing the promises to the
Open Source Community’. It is not so easy to show an example by
yourself. In my view, unless you’ve done yourself what you’re demanding
from others,

you do not really have moral right to pour fountains of harsh criticism
on them.

Wow Igor, I find your English impressive to say the least :wink:

I would like to jump in, but since this isn’t in advocacy i’ll abstain…

However … XFree86 is available for QNX Neutrino, file systems and
other system parts are portable … should the ‘Open Source
Community’ start a real open source project??


Yes, indeed please start a real one. Make sure it is something
yours.

  • igor
20

Igor Kovalenko wrote:

Armin Steinhoff wrote:

Igor Kovalenko wrote:

Why don’t you ‘open source’ one of your fieldbus drivers, Armin?

Igor, did I ever announce our product line DACHS becoming ‘open
source’?


No, you did not and that is exactly my point.

Did I ever do marketing with offering the sources of our product
line? NO!!

No one should be forced to offer ‘open sources’ … it must be
always a free decision and that decision must be respected.

I have spent several days in porting ‘open source’ tools … and it
was my free decision to make it available e.g. at
http://sourgeforge.net/projects/pyqnx → incl. all ported SOURCES!

Then you sure will have moral authority to teach them open source
ways… > :wink:

Moral authority?? Announcing ‘open source’, attracting the ‘Open
Source Community’ with promises, using open source applications for
their own purpose (e.g. gcc, gdb) … but not realizing the
promises to the ‘Open Source Community’.

What kind of moral is that ?


Speaking about promices, yes you have your point. But note, you’re also
using open source applications for your own (commercial) purposes,

Yes … and I differentiate carefully between the GNU GPL, the LGPL
and other none GNU licensing … e.g. the Python license.

however you do not appear to be in hurry to embrace open source model in
your own business.

Our product business has nothing to do with ‘open source’ and it is
our free decision to offer sources or not. OTOH, I have given back a
lot of ported open sources to the open source community. And be sure
… I will continue!

It is easy to criticize someone for ‘not realizing the promises to the
Open Source Community’.

Igor, as you know, we are doing always a ‘double-sale’ since 1992
when we offer our QNX based products, because of we have to convince
pot. customers about QNX. We were so stupid and mentioned in our
promotion that QNX6 (except for the kernel) will be open source.

And that is what harms our business today … last week at the
Embedded Systems we have heard again and again the question:
“When will we see the QNX sources??” What would you tell these LINUX
users who trusted us?? It’s not only our problem … that bizarre
behavior regarding ‘open sources’ will cost QSSL a lot of reputation
and QSSL will go on loosing projects…

OK Igor … your are invited to stay 4 days in our booth at the ISA
Expo in Sept. in Houston … just to give you the possibilty to
answer these questions and to hear these frustrated comments…

It is not so easy to show an example by yourself.

It’s very easy … visit http://sourgeforge.net/projects/pyqnx

However … XFree86 is available for QNX Neutrino, file systems and
other system parts are portable … should the ‘Open Source
Community’ start a real open source project??


Yes, indeed please start a real one. Make sure it is something
yours.

Don’t worry … there is already a lot of open source stuff available
from me!

Stackless Python 2.0 will come at next … and that is not only an
empty promise.

Armin