mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Eduard Bloch <edi@gmx.de>
To: Linus Torvalds <torvalds@osdl.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: cdrecord hangs my computer
Date: Sun, 7 Dec 2003 12:01:22 +0100	[thread overview]
Message-ID: <20031207110122.GB13844@zombie.inka.de> (raw)
In-Reply-To: <Pine.LNX.4.58.0312061429080.2092@home.osdl.org>

#include <hallo.h>
* Linus Torvalds [Sat, Dec 06 2003, 02:32:08PM]:

> > Hey, that "piece of crap" has burned one heck of a lot of ISO images of
> > Linux over the years.
> 
> And so does windows. That doesn't make it good.

But somehow most Windows programers have easy way to deal with devices,
they have clear paths to get hardware access where on Linux there is
often something not thought out well which ruins your day. Examples?

If you have worked on a SCSI generic device and wish to get all the
block devices associated with this one in upper level, how do you get
that information? I tried to find a way a while ago and it simply
sucked.

For details: http://bugs.debian.org/93633/ (CDROM TOC cache is not
flushed on mount, kernel does not see new sessions on the disk). And
don't tell me that I am stupid and I have simply to reject and reinsert
the CD as everybody does. It is not mandatory on non-Linux, and why? ;)
There must be a more simple way to flush the TOC cache in the block
device driver (where it should not be located whatsoever, IMO).

Another example: how to get a list of module names for each
module corresponding to drivers that have detected hardware? AFAICS
there is no policy, no subsystem to manage this and there are no
guidelines for the driver writers. The only thing you can do is looking
around in procfs, guessing with some hocus pocus.

How to assign a network interface name when loading the NIC driver?

> > How about a nod of thanks to the author before you tell him you don't
> > like his interface?
> 
> I tried to tell him why numbers are bad. Very politely, explaining that a
> lot of devices cannot be enumerated by a traditional "bus/dev/lun" scheme.

Imagine, there would be an internal mapping between devfs names and
"bus/dev/lun" so cdrecord&Co. could query it to get the scsi-generic
device name they need. There is almost always a way to a compromise.

> He basically cursed at me, and told me that that is how SCSI works. Never
> mind that IDE isn't SCSI, and even SCSI doesn't work that way any more
> (iSCSI comes to mind).

Sorry, but if you drive SCSI protocols over IDE hardware, using the same
terminology and the same control methods, why should it not be used as
such? Or was it because Windows works that way so we should make it
different (worse)?

Telling that someone is a dick is easy if you have the absolute power in
your area of control, but listening to him and extracting good arguments
may make sence sometimes.

MfG,
Eduard.


  reply	other threads:[~2003-12-07 11:01 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-06  8:01 Tero Knuutila
2003-12-06  8:12 ` Linus Torvalds
2003-12-06  8:54   ` Ethan Weinstein
2003-12-06 11:59     ` Måns Rullgård
2003-12-06 13:40     ` Wakko Warner
2003-12-06 14:37       ` John Bradford
2003-12-06 21:57       ` Linus Torvalds
2003-12-06 22:02         ` Larry McVoy
2003-12-06 22:32           ` Linus Torvalds
2003-12-07 11:01             ` Eduard Bloch [this message]
2003-12-07 16:18               ` Linus Torvalds
2003-12-08 16:21                 ` bill davidsen
2003-12-08 17:46                   ` Linus Torvalds
2003-12-09 12:38                     ` Bill Davidsen
2003-12-08 17:53                   ` Valdis.Kletnieks
2003-12-08 18:53                     ` Linus Torvalds
2003-12-08 19:40                       ` Valdis.Kletnieks
2003-12-09 14:50                         ` Ian Soboroff
2003-12-09 20:42                           ` Mikael Pettersson
2003-12-08 16:24                 ` Martin J. Bligh
2003-12-08 19:22                   ` dialectical deprecation " Bob
2003-12-09 21:19                     ` bill davidsen
2003-12-09 22:31                     ` David Lang
2003-12-09 21:51                       ` Måns Rullgård
2003-12-08  4:36           ` Bob
2003-12-08  4:51             ` Larry McVoy
2003-12-07  0:16         ` Wakko Warner
2003-12-07  3:31           ` William Lee Irwin III
2003-12-07  4:49           ` Linus Torvalds
2003-12-08 16:13         ` bill davidsen
2003-12-08 17:38           ` Linus Torvalds
2003-12-08 19:41             ` bluefaceplate demographics " Bob
2003-12-06 16:42     ` Linus Torvalds
2003-12-06 12:39 Tero Knuutila
2003-12-06 18:27 Tero Knuutila
2003-12-06 19:08 Tero Knuutila
2003-12-08  9:31 Douglas Gilbert
2003-12-11 12:56 ` Jens Axboe
2003-12-11 16:15   ` Linus Torvalds
2003-12-15 13:29 Paul Marinceu

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=20031207110122.GB13844@zombie.inka.de \
    --to=edi@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.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

all inboxes | Powered by JetHome®