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 patc
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
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
> 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
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, Kennet
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
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
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 from
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
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
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,
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.
>
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).
>> 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 dinne
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 fu
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
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
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 fr
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, it'
> 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 func
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-draggin
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
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 mai
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
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 Elisc
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).
> >
> >
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 t
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 it
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
29 matches
Mail list logo
