[lkml]   [2005]   [May]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: OT] Joerg Schilling flames Linux on his Blog
    Kyle Moffett <> wrote:

    > On May 25, 2005, at 18:46:55, Joerg Schilling wrote:

    > > The unability to give this kind of convenience to cdrecord users is
    > > a result
    > > of the refusal of the Linux kernel crew to include the kernel internal
    > > device instance numbers in the ioctl structures I need to read.
    > There is a specific reason that the numbers are _kernel_internal_!!!

    So if you really believe this, you should immediately remove all
    stuff under /proc.

    > I set up
    > my udev so that my green CD burner is /dev/green_burner, and my blue
    > CD burner
    > is /dev/blue_burner. Please tell me again why exactly I can't just
    > give the
    > option -dev=/dev/green_burner and have it use my green CD burner?

    Try to start with reading the cdrecord manual page. Your question
    is answered in there.....but if you issue a command that is only
    halfway correct you will never be able to get the full set of features from
    cdrtools. Using UNIX device names for SCSI devices is highly nonportable
    and for this reason not supported by a portable program like cdrecord.

    Cdrecord includes the needed features to do what you like, but do not
    asume that you will be able to force me to make nonportable and Linux
    specific interfaces a gauge for the design of a portable program.
    If you read the cdrecord man page, you know that you could
    happily call cdrecord dev=green_burner.....

    > That's a lot
    > easier than messing with random groups of 3 numbers and trying to
    > remember in
    > which order I plugged in my burners, and which kernel I'm running, so
    > I can
    > remember the enumeration order, etc.

    Aha, so you would prefer /dev/ also?

    Before trying to make inadequate comparisons and before you request
    inadequate similarities, it often helps a lot if you first try to look
    around and check whether your claims are really a tautology.

    > > Note that the fields are there but the information is intentionally
    > > obscured
    > > for come of the calls just to make the life of cdrecord useers
    > > harder :-(
    > The information is obscured because userspace shouldn't know or care

    If you read the LKML archives, it would be easy for you to prove that this
    is not true :-(

    The numbers are obscured _only_ in order to prevent me to implement a workaround
    for the fact that Linux does not implement _one_ unique interface for sending
    generic SCSI commands to all devices that talk SCSI.

    I aked for a non obscured interface in 2002 (note that the fields _are_ present
    inside the ioctl parameter structure) in order to hide this drawback from Linux
    users, but I have been told that the Linux developers don't like nice
    and _unique_ interfaces for their users.

    - The fields are in the ioctl structures for user land

    - The kernel knows the numbers that would allow libscg
    to detect duplikate drive appearances when trying to
    implement a global umbrella for all different SCSI
    interfaces in the Linux kernel

    - The kernel hides the fact only to make it impossible for
    cdrecord to implement a better user interface.

    > > If you don't call cdrecord as root, you will not be able to lock in
    > > memory
    > > and to raise priority in order to prevent buffer underuns.
    > I burn CDs fine all the time as a user, and I _don't_ need to lock
    > memory or
    > raise priority, because I have a good scheduler, plenty of RAM, and
    > dual CPUs.

    Do you really believe this? It would help a lot if you did a reality check.

    > It would be nice if you could let me leave on the _hardware_ BurnProof
    > technology designed to prevent that sort of thing, but it doesn't
    > appear to
    > fit with your ideals of 100% perfect CDs, does it? Besides, by the

    Again, try do do some reallity check.... Cdrecord by default uses the
    setup that grant best media quality. I asume you are able to read, so
    just read the man page and set up your defaults the way you like them.

    > burnproof). Personally, I'd rather have the latter.

    So why do you refuse to read the manual and to setup the parameters
    you like?

    > Did you try submitting a list of important SCSI commands and their
    > functions?
    > I suspect that if you provide a clear, concise list of harmless
    > commands,
    > they would be included in the available command set.

    Having such a list in inherently wrong. It never could be made correct.

    There are a lot of different drives with a lot of overlapping commands
    in the vendor unique part of the name space. Cdrecord needs the
    vendor unique commands for old writers in order to be able to write at
    all, and cdrecord needs the vendor unique commands in order to implement
    the nice features people like for their convenience.

    Nut even in the non vendor unique part the list in Linux is incomplete.

    And please note: Cdrecord uses some of the commands that are used for
    firmware upgrade in order to do DMA speed metering........ This is
    definitely _not_ a security issue with cdrecord.
    In special on Linux, users frequelty did complain about insufficient
    DMA speed before I did add this feature. Not cdrecord refuses to write
    faster than possible after metering the transfer speed from/to the drive.

    In case you don't understand this correectly, let me explain:

    A security problem may only be correctly dealt with by having a
    coherent and consistent security strategy. The SCSI op code table
    is not part of a security strategy but just a bad hack.


    -- (home) Jörg Schilling D-13353 Berlin (uni) (work) Blog:
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-05-27 11:52    [W:0.040 / U:21.968 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site