hi, there!
On Thu, Feb 28, 2002 at 09:58:00PM +0100, Søren Schmidt wrote:
Hmm, why do we need to add new layers and loss of functionality
to the ATAPI devices ?
Many many many people would like to be able to use cdrecord to burn data
to cd's so that all the front-ends to cdrecord
It seems Max Khon wrote:
On Thu, Feb 28, 2002 at 09:58:00PM +0100, S?ren Schmidt wrote:
Hmm, why do we need to add new layers and loss of functionality
to the ATAPI devices ?
Many many many people would like to be able to use cdrecord to burn data
to cd's so that all the
According to Thomas Quinot:
is one known pending issue with this code: on *some* machines,
patched kernels hang at boot time, immediately after registering
Thomas knows it already but I'd to mention that one of these machines is a
dual PIII/800 running 4.4-STABLE/SMP. I haven't tried the patch
An updated version of the ATAPI/CAM patches is available from
http://www.cuivre.fr.eu.org/~thomas/atapicam/
This version contains no functional changes, but synchronize with
recent modifications to the generic ATAPI code.
As always, I would be interested in any feedback. Specifically, there
is
This is definitly something that is needed..
The question is whether the CAM and ATAPI authors feel it is
right. We are guided by them (even though we desperatly need this).
Personally even if not perfect.. it's better than nothing and we should
probably commit something like it. or based on
On Thu, Feb 28, 2002 at 10:49:18 -0800, Julian Elischer wrote:
This is definitly something that is needed..
The question is whether the CAM and ATAPI authors feel it is
right. We are guided by them (even though we desperatly need this).
Personally even if not perfect.. it's better than
It seems Kenneth D. Merry wrote:
On Thu, Feb 28, 2002 at 10:49:18 -0800, Julian Elischer wrote:
This is definitly something that is needed..
The question is whether the CAM and ATAPI authors feel it is
right. We are guided by them (even though we desperatly need this).
Personally
I think it's better to commit it now and have it fixed in situ.
It's new functionality so committing it with bugs will not break anyone.
it will however get more work done on it and more testing.
On Thu, 28 Feb 2002, Kenneth D. Merry wrote:
On Thu, Feb 28, 2002 at 10:49:18 -0800, Julian
On Thu, 28 Feb 2002, Søren Schmidt wrote:
I'll quit the ATA/ATAPI development/maintenance if this goes in quickly.
What? Are you looking at the same patches that everyone else is?
I'd expect this sort of foot-dragging if the patch were intrusive to the
ATA drivers but its not.
--
| Matthew
In message [EMAIL PROTECTED], Jul
ian Elischer writes:
I think it's better to commit it now and have it fixed in situ.
It's new functionality so committing it with bugs will not break anyone.
it will however get more work done on it and more testing.
[...]
Well you are one of the main CAM
It seems Matthew N. Dodd wrote:
On Thu, 28 Feb 2002, Søren Schmidt wrote:
I'll quit the ATA/ATAPI development/maintenance if this goes in quickly.
What? Are you looking at the same patches that everyone else is?
Read the rest of my mail, the problem is not the patches as much
as it is all the
On Thu, Feb 28, 2002 at 02:45:04PM -0500, Matthew N. Dodd wrote:
On Thu, 28 Feb 2002, Søren Schmidt wrote:
I'll quit the ATA/ATAPI development/maintenance if this goes in quickly.
What? Are you looking at the same patches that everyone else is?
I'd expect this sort of foot-dragging if
Hmm, why do we need to add new layers and loss of functionality
to the ATAPI devices ?
Many many many people would like to be able to use cdrecord to burn data
to cd's so that all the front-ends to cdrecord will work. It's much nicer
than memorizing mkisofs commandline switches :-)
What
Poul-henning.
What crack are you on?
Have you looked at the patches in question?
They are small and non-intrusive.
We are relying on the ATA maintainer to tell us whether they
are dangerous, but they are so small that we should look at
fast-tracking them if possible.
Even if it was broken,
where dod sis post his email..?
I never saw it
On Thu, 28 Feb 2002, Kenneth Culver wrote:
Hmm, why do we need to add new layers and loss of functionality
to the ATAPI devices ?
Many many many people would like to be able to use cdrecord to burn data
to cd's so that all the
On Thu, 2002-02-28 at 12:57, Sxren Schmidt wrote:
It seems Matthew N. Dodd wrote:
On Thu, 28 Feb 2002, Søren Schmidt wrote:
I'll quit the ATA/ATAPI development/maintenance if this goes in quickly.
What? Are you looking at the same patches that everyone else is?
Read the rest of my
It seems Kenneth Culver wrote:
Hmm, why do we need to add new layers and loss of functionality
to the ATAPI devices ?
Many many many people would like to be able to use cdrecord to burn data
to cd's so that all the front-ends to cdrecord will work. It's much nicer
than memorizing mkisofs
It seems Scott Long wrote:
As I have stated several times, I have no problem with ATAPI being
sent through CAM as long as the usual way stays (some of us cannot
afford the weight of those extra layers, nor loose functionality).
I'd do the integration somewhat differently to even further
On Thu, 2002-02-28 at 14:06, Søren Schmidt wrote:
It seems Scott Long wrote:
As I have stated several times, I have no problem with ATAPI being
sent through CAM as long as the usual way stays (some of us cannot
afford the weight of those extra layers, nor loose functionality).
I'd do
What functionality is lost by this ability?
Compare the features of the ATAPI vs SCSI CD drivers..
This is exactly why I'd like to see this code merged. The hardware
changes too rapidly. The specs change too rapidly but MMC is MMC.
More of us are getting wives we need to take out to dinner
It seems Justin T. Gibbs wrote:
What functionality is lost by this ability?
Compare the features of the ATAPI vs SCSI CD drivers..
This is exactly why I'd like to see this code merged. The hardware
changes too rapidly. The specs change too rapidly but MMC is MMC.
Exactly.
More of us
It seems Scott Long wrote:
I'm mainly raising my hand to take the abuse that will no doubt happen
once in a while.
Sure, maybe we should make Thomas a committer so he could look after
it himself ? Interested ? Got the time ? I'm all ears for volounteers...
Ummm, I'm
Wow /that's/ a thread ;)
On Thu, 28 Feb 2002, Søren Schmidt wrote:
I'll quit the ATA/ATAPI development/maintenance if this goes in quickly.
First of all I'd like to make two points:
* Søren is doing a great job as ATA maintainer, and it would be a
Bad Thing to have him quit;
* I am
Le 2002-02-28, Søren Schmidt écrivait :
I have no problem with you doing it, I was just fishing for getting
Thomas into the net also, we need all the hands we can get :)
As I mentioned I am entirely willing to take charge of the care
and feeding of the bugs I wrote.
Thomas.
--
[EMAIL
I think Thomas is doing here a quite good job and it is also to him to
decide to include his sources and maybe maintain them. The ata sources have
changed a lot the last weeks, so until Thomas thinks his sources are under
heavy development too, both should do their jobs and we've some patches
We have CVS
Why not commit the prototype now and update it as people get the corner
cases worked out?
The code doesn't interfere with either the CAM system or the ATAPI system
that I can see.
On Thu, 28 Feb 2002, Jan Stocker wrote:
I think Thomas is doing here a quite good job and it is also
On Thu, 2002-02-28 at 23:15, Julian Elischer wrote:
We have CVS
Okay.. thats a piece software..
Why not commit the prototype now and update it as people get the corner
cases worked out?
If Thomas can and will maintain it, ok... else read my comment from my
last mail...
The code doesn't
Umm, I don't remember where he posted it, but it wasn't posted privately.
Most likely since I'm using pine, it was posted to freebsd-current and
freebsd-scsi.
Ken
On Thu, 28 Feb 2002, Julian Elischer wrote:
where dod sis post his email..?
I never saw it
On Thu, 28 Feb 2002, Kenneth
Hmm, cdrecord can be used with the ATAPI sunsystem as it is, I did
patches for this long ago, but noone picked it up as a port...
I remember you saying that you had these, but you weren't willing to
release them for some reason; something to do with the GPL...
What functionality is lost by
29 matches
Mail list logo
