CDR Support...

What is the status on the CDR support? I know QNX released some
“experimental” libraries and a patch/hacked copy of cdrecord, but that
hasn’t been merged into the source tree on the CDRecord sight and I haven’t
seen or heard hardly anything other than the original announcement. The
patch that is required for mkisofs is not on a FAQ or a web page where it’s
easy to find, and I can’t find it on a news groups without wasting a lot of
time.

The ability to log data to a CD is an assumption with modern computers,
and is well support on other OSes include RT Linux. In industrial
environments it can be considered essential to have data logging. It is not
wise for QNX not to give some priority to this type of functionality, you
don’t buy a RTOS so you can write basic services or hack them yourself. You
should only have to write drivers/utilities for custom hardware and/or
uncommon configurations. In modern times the CDR is as ubiquitous as a
floppy was on the early PCs, you shouldn’t have to “contact you sales
representative” to use a CDR any more than you should to use a floppy. This
is especially true when free RT OSes that are distributed in source form
give you that functionality.

FWIW:
http://hostwork.com/matt/qnx/
http://www.hostwork.com/matt/qnx/ports/cdrtools_x86-2.01a15-x86-public.qpr

UDF would be nice, but I don’t even Linux has bedded down that yet…

This work for me using the Sony CD-RW CRX225E

Bob Smith wrote:

What is the status on the CDR support? I know QNX released some
“experimental” libraries and a patch/hacked copy of cdrecord, but that
hasn’t been merged into the source tree on the CDRecord sight and I haven’t
seen or heard hardly anything other than the original announcement. The
patch that is required for mkisofs is not on a FAQ or a web page where it’s
easy to find, and I can’t find it on a news groups without wasting a lot of
time.

The ability to log data to a CD is an assumption with modern computers,
and is well support on other OSes include RT Linux. In industrial
environments it can be considered essential to have data logging. It is not
wise for QNX not to give some priority to this type of functionality, you
don’t buy a RTOS so you can write basic services or hack them yourself. You
should only have to write drivers/utilities for custom hardware and/or
uncommon configurations. In modern times the CDR is as ubiquitous as a
floppy was on the early PCs, you shouldn’t have to “contact you sales
representative” to use a CDR any more than you should to use a floppy. This
is especially true when free RT OSes that are distributed in source form
give you that functionality.

This was recently discussed over in the devtools group, under
“making a bootable QNX CD”. The consensus is that it is possible,
but it only works for gurus with a lot of free time.

Supposedly the necessary fixes to the CD driver were going
into 6.2.1NC, but it turns out that they aren’t in there.

I’m really looking forward to the next minor QNX release. There’s
quite a bit of dirty laundry in the 6.2.1 build, as previously
discussed in other messages. Too much stuff that should just
work takes “tweaking”. 6.2.0 was cleaner. A cleanup release is needed.

John Nagle
Team Overbot

Bob Smith wrote:

What is the status on the CDR support? I know QNX released some
“experimental” libraries and a patch/hacked copy of cdrecord, but that
hasn’t been merged into the source tree on the CDRecord sight and I haven’t
seen or heard hardly anything other than the original announcement. The
patch that is required for mkisofs is not on a FAQ or a web page where it’s
easy to find, and I can’t find it on a news groups without wasting a lot of
time.

The ability to log data to a CD is an assumption with modern computers,
and is well support on other OSes include RT Linux. In industrial
environments it can be considered essential to have data logging. It is not
wise for QNX not to give some priority to this type of functionality, you
don’t buy a RTOS so you can write basic services or hack them yourself. You
should only have to write drivers/utilities for custom hardware and/or
uncommon configurations. In modern times the CDR is as ubiquitous as a
floppy was on the early PCs, you shouldn’t have to “contact you sales
representative” to use a CDR any more than you should to use a floppy. This
is especially true when free RT OSes that are distributed in source form
give you that functionality.

John,

I remember reading that thread/discussion in qdn.public.qnxrtp.devtools, but
I can’t find it anymore. Do they rename / delete threads periodically? I am
using outlook from windoze.

Thanks,

John Eddy


“John Nagle” <nagle@downside.com> wrote in message
news:bh3f7k$lbe$1@inn.qnx.com

This was recently discussed over in the devtools group, under
“making a bootable QNX CD”. The consensus is that it is possible,
but it only works for gurus with a lot of free time.

Supposedly the necessary fixes to the CD driver were going
into 6.2.1NC, but it turns out that they aren’t in there.

I’m really looking forward to the next minor QNX release. There’s
quite a bit of dirty laundry in the 6.2.1 build, as previously
discussed in other messages. Too much stuff that should just
work takes “tweaking”. 6.2.0 was cleaner. A cleanup release is needed.

John Nagle
Team Overbot

Bob Smith wrote:
What is the status on the CDR support? I know QNX released some
“experimental” libraries and a patch/hacked copy of cdrecord, but that
hasn’t been merged into the source tree on the CDRecord sight and I
haven’t
seen or heard hardly anything other than the original announcement. The
patch that is required for mkisofs is not on a FAQ or a web page where
it’s
easy to find, and I can’t find it on a news groups without wasting a lot
of
time.

The ability to log data to a CD is an assumption with modern
computers,
and is well support on other OSes include RT Linux. In industrial
environments it can be considered essential to have data logging. It is
not
wise for QNX not to give some priority to this type of functionality,
you
don’t buy a RTOS so you can write basic services or hack them yourself.
You
should only have to write drivers/utilities for custom hardware and/or
uncommon configurations. In modern times the CDR is as ubiquitous as a
floppy was on the early PCs, you shouldn’t have to “contact you sales
representative” to use a CDR any more than you should to use a floppy.
This
is especially true when free RT OSes that are distributed in source form
give you that functionality.

John,

Never mind… it was just outlook.
I did a reset on the newsgroup and it brought back 4387 entries. It must
locally remove older threads from the local list.

Thanks,

John Eddy

“John Nagle” <nagle@downside.com> wrote in message
news:bh3f7k$lbe$1@inn.qnx.com

This was recently discussed over in the devtools group, under
“making a bootable QNX CD”. The consensus is that it is possible,
but it only works for gurus with a lot of free time.

Supposedly the necessary fixes to the CD driver were going
into 6.2.1NC, but it turns out that they aren’t in there.

I’m really looking forward to the next minor QNX release. There’s
quite a bit of dirty laundry in the 6.2.1 build, as previously
discussed in other messages. Too much stuff that should just
work takes “tweaking”. 6.2.0 was cleaner. A cleanup release is needed.

John Nagle
Team Overbot

Bob Smith wrote:
What is the status on the CDR support? I know QNX released some
“experimental” libraries and a patch/hacked copy of cdrecord, but that
hasn’t been merged into the source tree on the CDRecord sight and I
haven’t
seen or heard hardly anything other than the original announcement. The
patch that is required for mkisofs is not on a FAQ or a web page where
it’s
easy to find, and I can’t find it on a news groups without wasting a lot
of
time.

The ability to log data to a CD is an assumption with modern
computers,
and is well support on other OSes include RT Linux. In industrial
environments it can be considered essential to have data logging. It is
not
wise for QNX not to give some priority to this type of functionality,
you
don’t buy a RTOS so you can write basic services or hack them yourself.
You
should only have to write drivers/utilities for custom hardware and/or
uncommon configurations. In modern times the CDR is as ubiquitous as a
floppy was on the early PCs, you shouldn’t have to “contact you sales
representative” to use a CDR any more than you should to use a floppy.
This
is especially true when free RT OSes that are distributed in source form
give you that functionality.