linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthias Andree <matthias.andree@gmx.de>
To: Joerg Schilling <schilling@fokus.fraunhofer.de>
Cc: psusi@cfl.rr.com, mrmacman_g4@mac.com, matthias.andree@gmx.de,
	linux-kernel@vger.kernel.org, jengelh@linux01.gwdg.de,
	bzolnier@gmail.com, acahalan@gmail.com
Subject: Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]
Date: Tue, 31 Jan 2006 12:22:23 +0100	[thread overview]
Message-ID: <20060131112223.GA23149@merlin.emma.line.org> (raw)
In-Reply-To: <43DF403F.nail2RF310RP6@burner>

Joerg Schilling schrieb am 2006-01-31:

> > It certainly does return something useful, just not what you are looking 
> > for.  It does not return information that allows you to cleanly build 
> > your bus:device:lun view of the world, but it does return sufficient 
> > information to enumerate and communicate with all devices in the 
> > system.  Is that not sufficient to be able to implement cdrecord?  If it 
> > is, then the real issue here is that you want Linux to conform to the 
> > bus:device:lun world view, which it seems many people do not wish to do. 
> 
> It does not allow libscg to find all devices.

On my system,

sudo cdrecord -scanbus ; \
sudo cdrecord -scanbus dev=ATA:

finds all devices that talk ATAPI, SCSI, MMC.

> > Maybe it would be more constructive if you were to make a good argument 
> > for why the bus:device:lun view is better than /dev/*, but right now it 
> > seems to me that they are just two different ways of doing the same 
> > thing, and you prefer one way while the rest of the Linux developers 
> > prefer the other. 
> 
> It would help if someone would give arguments why Linux does treat all 
> SCSI devices equal, except for ATAPI transport based ones.

1a The question is rather, what is the reason that you claim libscg is
allegedly unable to find all devices?

  1b Not scanning all of the devices perhaps?

  1c Not asking the right enumeration interface perhaps?

2 And what devices are actually missing?
Name tangible devices or groups, not phantoms that no-one uses.

3 Why does libscg need to care at all which kernel driver provides SG_IO?
The device node give access to the target the user desires. Add serial
number listing to -scanbus to make those happy that have several drives
of the same brand and model.

4 Why have you not yet responded to the suggestion to use freedesktop.org
HAL to enumerate devices?

Summarizing past discussions, it appears as though you have not
presented sufficiently substantiated arguments to prove libscg is
actually missing out on device, and not sufficient evidence to convince
kernel developers to CHANGE things.

The same way as you want them to justify their using device nodes
instead bus:id:lun to map everything into a narrow namespace, they can
make you justify your request. Fact is that cdrecord+libscg appear to
work well enough so that nobody wants to care about theoretical gaps
that have no practical impact.

And given that libscg's namespace is already transport:bus:id:lun which
comprises /dev/hd* and /dev/sg* so nicely that CD writing works today,
it seems hard to justify changes beyond 1. removing irritating warnings
from cdrecord/libscg, 2. making libscg actually scan all transports and
not just one when looking for devices.

It is pretty clear now that the Linux kernel developers do not care if
your application bitches at users because you don't like a particular
interface.

-- 
Matthias Andree

  reply	other threads:[~2006-01-31 11:22 UTC|newest]

Thread overview: 89+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-27 16:37 CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] Bartlomiej Zolnierkiewicz
2006-01-29 11:01 ` Joerg Schilling
2006-01-29 11:15   ` Jan Engelhardt
2006-01-29 11:28     ` Matthias Andree
2006-01-30 15:24     ` Joerg Schilling
2006-02-05 12:03       ` Jan Engelhardt
2006-02-06 16:29         ` Joerg Schilling
2006-02-06 17:17           ` René Rebe
2006-02-06 18:02           ` Matthias Andree
2006-01-29 11:26   ` Matthias Andree
2006-01-29 20:41     ` Jan Engelhardt
2006-01-29 20:50       ` Joerg Schilling
2006-01-29 21:28         ` Albert Cahalan
2006-01-30 16:11           ` Joerg Schilling
2006-01-30 16:31             ` Albert Cahalan
2006-01-30 16:35               ` Joerg Schilling
2006-01-30 17:08                 ` Matthias Andree
2006-01-30 17:14                   ` Joerg Schilling
2006-01-30 17:30                     ` Matthias Andree
2006-01-30 17:37                       ` Joerg Schilling
2006-01-30 17:49                         ` Matthias Andree
2006-01-30 20:22                         ` James Courtier-Dutton
2006-01-31 10:17                         ` Andreas Jellinghaus
2006-01-30 20:24                     ` Phillip Susi
2006-01-31 10:47                       ` Joerg Schilling
2006-01-31 11:22                         ` Matthias Andree [this message]
2006-02-01  0:15                         ` Bill Davidsen
2006-02-01  7:45                         ` Tejun Heo
2006-02-01 16:41                           ` Joerg Schilling
2006-01-31 23:55         ` Bill Davidsen
2006-02-01 15:06           ` Joerg Schilling
2006-01-30 15:25     ` Joerg Schilling
2006-01-30 17:09       ` Matthias Andree
2006-01-30 17:15         ` Joerg Schilling
2006-01-30 23:26           ` Pavel Machek
2006-02-01 15:51             ` Jan Engelhardt
2006-01-31  1:43   ` Patrick McFarland
2006-01-31  1:47     ` CD writing in future Linux try #2 David S. Miller
2006-01-31 11:13       ` Gerhard Mack
2006-01-31 11:18         ` David S. Miller
2006-02-01  0:28           ` Bill Davidsen
2006-02-01 15:12             ` Joerg Schilling
2006-02-01 15:25               ` Matthias Andree
2006-02-01 16:32                 ` Joerg Schilling
2006-02-02 16:24                 ` Jan Engelhardt
2006-02-02 16:29             ` Jan Engelhardt
2006-02-02 18:37               ` Bill Davidsen
2006-02-03 12:58                 ` Joerg Schilling
2006-02-03 13:15                   ` Matthias Andree
2006-02-03 16:43                     ` Joerg Schilling
2006-02-03 13:30                   ` linux-os (Dick Johnson)
2006-02-03 19:27                   ` Bill Davidsen
2006-02-01  4:49           ` Albert Cahalan
2006-02-01  7:56             ` jerome lacoste
2006-02-01 16:42               ` Joerg Schilling
2006-02-02  0:30                 ` Kurt Wall
2006-02-01 11:33             ` Rene Herman
2006-02-01 16:21               ` Jon Agirre
2006-02-02 16:35               ` Jan Engelhardt
2006-02-06 23:15                 ` Peter Chubb
2006-02-07  5:00                   ` Albert Cahalan
2006-02-01 16:36             ` Joerg Schilling
2006-02-01 17:01               ` Matthias Andree
2006-02-02 19:17             ` Bill Davidsen
2006-01-31 16:46         ` Lennart Sorensen
2006-01-31 14:15       ` linux-os (Dick Johnson)
     [not found]     ` <515e525f0601302205h4a845f36u12b946515759239a@mail.gmail.com>
2006-01-31  6:46       ` CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] Kyle Moffett
2006-01-31  8:55     ` Pekka Enberg
2006-02-01  0:25     ` Jesper Juhl
2006-02-02 16:45       ` Jan Engelhardt
2006-02-10 17:58 ` CD-blanking leads to machine freeze with current -git [was: Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]] Marc Koschewski
2006-02-10 19:19   ` Phillip Susi
2006-02-10 19:39     ` Gene Heskett
2006-02-10 20:12       ` Kyle Moffett
2006-02-10 21:00         ` Gene Heskett
2006-02-10 21:00     ` Marc Koschewski
2006-02-10 21:26       ` Phillip Susi
2006-02-10 21:35         ` Lennart Sorensen
2006-02-11 15:16         ` CD-blanking leads to machine freeze with current -git Jan Engelhardt
2006-02-11 15:25           ` Marc Koschewski
2006-02-11 15:35             ` Doug McNaught
2006-02-11 15:44               ` Marc Koschewski
2006-02-10 23:23       ` CD-blanking leads to machine freeze with current -git [was: Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]] Alan Cox
2006-02-10 23:41         ` Marc Koschewski
2006-02-10 23:50           ` CD-blanking leads to machine freeze with current -git Doug McNaught
2006-02-10 23:56           ` CD-blanking leads to machine freeze with current -git [was: Re: CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ]] Alan Cox
2006-02-11  1:03       ` hackmiester (Hunter Fuller)
2006-02-11  1:08         ` Marc Koschewski
     [not found] <5zENZ-72l-47@gated-at.bofh.it>
     [not found] ` <5AiBB-5AH-17@gated-at.bofh.it>
     [not found]   ` <5AiV2-62l-7@gated-at.bofh.it>
     [not found]     ` <5AJ9s-2go-23@gated-at.bofh.it>
     [not found]       ` <5AKHI-4IV-5@gated-at.bofh.it>
     [not found]         ` <5AKRr-4V5-19@gated-at.bofh.it>
2006-01-31  1:01           ` CD writing in future Linux try #2 [ was: Re: CD writing in future Linux (stirring up a hornets' nest) ] Robert Hancock

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=20060131112223.GA23149@merlin.emma.line.org \
    --to=matthias.andree@gmx.de \
    --cc=acahalan@gmail.com \
    --cc=bzolnier@gmail.com \
    --cc=jengelh@linux01.gwdg.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mrmacman_g4@mac.com \
    --cc=psusi@cfl.rr.com \
    --cc=schilling@fokus.fraunhofer.de \
    /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;
as well as URLs for NNTP newsgroup(s).