lkml.org 
[lkml]   [2006]   [Feb]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: CD writing in future Linux (stirring up a hornets' nest)
Date
On Monday 13 February 2006 08:40, Joerg Schilling wrote:
> "D. Hazelton" <dhazelton@enter.net> wrote:
> > > Name a single program (not using libscg) that implements user space
> > > SCSI and runs on as many platforms as cdrecord/libscg does.
> >
> > I'm not the maintainer of a program, and hence I don't have to.
> >
> > But why in the hell do you even _need_ SCSI in userspace when the kernel
> > provides complete facilities? And even then your argument is specious,
> > since
>
> Then please try to inform yourself in order to understand that you are
> wrong.

Inform myself? Before this discussion even began I had spent hours trying to
figure out how to use libscg and decided to just use the provided linux
systems and worry about porting to other systems if I ever finished the
project. As far as I'm concerned, Linux provides enough of an abstraction
layer that anyone with a bit of programming skill and access to the proper
documentation can do _anything_ they want.

A personal attack like this is how flame wars get started - I will not be
party to one. And again you show your colors as a troll, by making a personal
attack. The only saving grace is that you did explain yourself.

>
> libscg abstracts from a kernel specific transport and allows to write OS
> independent applications that rely in generic SCSI transport.

I still think that on modern operating systems libscg needs to be nothing more
than a wrapper around the OS specific code. Anything added extra beyond that
is actually unneeded.

> For this reason, it is bejond the scope of the Linux kernel team to decide
> on this abstraction layer. The Linux kernel team just need to take the
> current libscg interface as given as _this_ _is_ the way to do best
> abstraction.

Why is it the best? Because you wrote it? Beyond cdrtools I have seen only one
user of it (and I don't know that that program hasn't been silently folded
into cdrtools recently). The fact that no one else has written a SCSI wrapper
means a few things. One: That nobody else has ever seen the need for it. Two:
That most programmers are like me - lazy and unwilling to "reinvent the
wheel" for any project. In truth, it's not an "either-or" it's both of those
reasons.

And my point still remains - applications and libraries must _WORK_ _WITHIN_
the framework provided by the OS. No application or library that attempts to
define the way an OS works is valid - this is a simple fact that you seem
unable to grasp.

> The Linux kernel team has the freedom to boycott portable user space SCSI
> applications or to support them.

so I'm guessing you think that your userbase is happy with your scheme? If
they are anything like most people I know they have just resigned themselves
to using a bad interface or they use a GUI that hides the complexities of the
interface from them.

And even then, as someone else pointed out, two drives that are identical in
all respects except color, plugged onto two seperate busses, will appear the
same in the scanbus listing. How can a user tell them apart?

DRH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-02-14 00:07    [W:0.208 / U:5.140 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site