Re: CD writing in future Linux (stirring up a hornets' nest)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jens Axboe wrote:
On Thu, Jan 26 2006, Jan Engelhardt wrote:

You just want the device naming to reflect that. The user should not
need to use /dev/hda, but /dev/cdrecorder or whatever. A real user would
likely be using k3b or something graphical though, and just click on his
Hitachi/Plextor/whatever burner. Perhaps some fancy udev rules could
help do this dynamically even.

And if you have multiple cdwriters? Then (cf. other posts) one has /dev/cdrecorder0 /dev/cdrecrder1, etc. To me, that's just as bad as having /dev/sg0 and /dev/sg1, because you don't have a clue at first sight what it maps to.


/dev/plextorwriter and /dev/hpwriter or whatever, it's just naming.


"ls -l"? Sure, if cdrecorder0 was a symlink, but it does not work when it's not (= a block device in essence then).
And I'm sure there's an analog program to "ls" to find what sg0 maps to.


You expect the gui user to follow symlinks to find out?

As opposed to? That's not a rhetorical question, please don't blow it off, what is the way for a user to go from /dev/sg0 to find out what device is really there?

What is not easily available in Linux is a nice single place to find out what mass storage (disk/optical/floppy/ZIP/LS120/tape) devices are on the system, and what the system calls them. Because for low tech users udev is the problem, not the solution. The user doesn't want to tell the system what to call the device, he wants to see what's there, and that includes serial numbers of drives (where available) because if a user has several drives it's likely that they are identical.

Telling the users to "cat /proc/scsi/scsi" and
 for n in /proc/ide/hd?; do echo -n "$n: "; cat $n/model; done
is not a substitute for a presentation useful to programs and people alike. It could be in /proc or /sys or wherever is flavor of the day, but it would sure make things easier for the users. And before someone suggests that a program could generate this, a program would constantly chase the changing presentation of the information, a documented "file" in /proc or /sys would allow all applications to look in one place for the information.

Instead of having the user tell the system what to call a device, let the system tell the user what it is called. Then the kernel could change without breaking anything in application land.

--
   -bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
 last possible moment - but no longer"  -me
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux