public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Kern Alexander <alexander.kern@siemens.com>
Cc: "'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>,
	"'alex.kern@gmx.de'" <alex.kern@gmx.de>
Subject: Re: PATCH: cdrecord: avoiding scsi device numbering for ide devic es
Date: Mon, 9 Aug 2004 20:38:58 +0200	[thread overview]
Message-ID: <20040809183857.GD28302@suse.de> (raw)
In-Reply-To: <DB51EBFA5812D611B6200002A528BC270379BF72@khes002a.khe1.siemens.de>


(if you don't cc me, I don't see your mail. it's been 4 days now. always
cc on linux-kernel, it's the etiquette!)

On Thu, Aug 05 2004, Kern Alexander wrote:
> Jens Axboe wrote:
> 
> > On Thu, Aug 05 2004, Joerg Schilling wrote:
> > 
> >>>From: Jens Axboe <axboe@suse.de>
> >>
> >>>ATA method is misnamed, it's really SG_IO that is used. And you want to
> >>>use that regardless of the device type, SCSI or ATAPI. There's no such
> >>>thing as an ATA burner, and there's no need to differentiate between
> >>>SCSI or ATAPI CD-ROM's when burning - SG_IO is the method to use. So
> >>>forget browsing /proc/ide and other hacks.
> >>
> >>I am sorry but as Linux already has 6 different interfaces for sending 
> >>Generic SCSI commands and thus, we are running out of names.
> >>
> >>Let me give you an advise: consolidate Linux so that is does only need
> >>/dev/sg and fix the bugs in ide-scsi instead of constantly inventing new
> >>unneeded interfaces.
> > 
> > 
> > That's been the general direction for quite some time, just that SG_IO
> > is the preferred method since that works all around. You were the one
> > that merged support for the CDROM_SEND_PACKET interface, which has
> > _never_ been advertised as a way to burn CDs in Linux. I'd suggest you
> > remove that.
> > 
> Silly, as I suggested a patch to Joerg, it was the uniquely ability to
> burn without ide-scsi. And known you, it simply works, it let me to
> scan for burners(what SG_IO cannot), it works in 2.4.X and 2.6.X.

Yes it simply works, as long as it works...

> Make SG_IO better and CDROM_SEND_PACKET will die, without your
> suggestions.

SG_IO is perfect as is, what problems are you referring to?

> P.S. I'm know that CDROM_SEND_PACKET has a overhead, by me it's 4%. I
> can live with it.

In 2.6, there is basically zero extra overhead with CDROM_SEND_PACKET,
since it's just a small wrapper on top of SG_IO (see scsi_ioctl.c if you
are curious), so you cannot measure a performance difference between the
two there.

In 2.4 it's orders of magnitude slower, since it will not use
CDROM_SEND_PACKET and it puts unnecessary strain on the memory allocator
to larger chunks of physically contigous memory. Note that you will not
see interrupt handler load if you are only doing casual performance
monitoring.

-- 
Jens Axboe


      reply	other threads:[~2004-08-09 18:42 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-05 16:00 PATCH: cdrecord: avoiding scsi device numbering for ide devic es Kern Alexander
2004-08-09 18:38 ` Jens Axboe [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040809183857.GD28302@suse.de \
    --to=axboe@suse.de \
    --cc=alex.kern@gmx.de \
    --cc=alexander.kern@siemens.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox