Linux-Development-Sys Digest #608, Volume #6 Fri, 9 Apr 99 23:14:36 EDT
Contents:
Re: CodeWarror for Linux (was: Re: Programming tools for ...) ([EMAIL PROTECTED])
2.2.5-ac6 won't boot on Alpha (Albrecht Jacobs)
Re: CodeWarror for Linux (was: Re: Programming tools for ...) (David M. Cook)
Re: CodeWarror for Linux (was: Re: Programming tools for ...) ([EMAIL PROTECTED])
scanning scsi-cdrom ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Crossposted-To:
comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.help,comp.unix.programmer
Subject: Re: CodeWarror for Linux (was: Re: Programming tools for ...)
Date: Fri, 9 Apr 1999 18:48:05 -0500
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
> On Fri, 9 Apr 1999 14:57:27 -0500, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >In article <GbgP2.902$[EMAIL PROTECTED]>,
> >[EMAIL PROTECTED] says...
> >> <[EMAIL PROTECTED]> wrote:
> >>
> >> >What I don't understand is why the low level syntax of, say, make hasn't
> >> >been used as a foundation to build upon in an IDE. Most professional
> >> >developers would then use IDEs that are based upon an open standard so no
> >> >proprietary lock-in could occur (many IDEs would be available that
> >> >basically just produce a make file and interface gcc and RCS e.g.).
> >> >Personally, I think UNIX people like things complex for job security or
> >> >some bull like that. Perhaps it just goes back to the failing of UNIX:
> >> >no simple GUI std??
>
> There is enough GUI software for Unix to show that GUI stuff is possible. If
> programmers really thought an IDE would be such a great benefit they would
> do it.
That's probably the problem in a nutshell. Programmers hold back the
potential cuz they can't see beyond the realm they are currently in.
> However, since they are on Unix already, they know thet the Unix shell
> is as good an IDE as you can get. Until we start writing code that isn't
> text of course. For editing plain old text the Unix tools approach is about
> as good as it gets. Amazing amounts of reuse. Amazing expressive power.
>
> >>
> >> I think you are barking up the wrong tree. Let me explain.
> >> Make is used as a foundation for more powerful tools such as
> >> autoconf, imake, automake, etc. These are not GUI tools for an IDE, but
> >> rather character app based tools that get jobs done for people that
> >> need to do them. So the premise that nobody builds on top of make
> >> is for Unix is wrong. The hypothesis that people prefer tools that
> >> are not novice-friendly for job security is also wrong.
> >
> >> It shouldn't
> >> be hard to see that there is going to be a big difference in the
> >> typical style of free software applications that are created or enhanced
> >> by individuals, to personally help them get their work done vs.
> >> the style of a commercial application that is developed by a software
> >> company to sell to the largest number of users.
> >
> >That's exactly what's hard to see: why the fundamentals of process
> >improvement haven't been accepted.
> >
> >> The difference in
> >> motivations and payoffs and intended user community should be
> >> pretty clear.
> >
> >Nope, not at all. How would having a decent IDE hurt??
>
> It wouldn't but the time it would take to develop has instead been put
> into developing better tools based development approaches. Emacs is an IDE.
>
> GUI construction tools are missing currently, but again that's because no
> one has really needed them enough to write them (but that is changing)...
>
> For writing code, a GUI doesn't win you much.
For _building_product_ it does. Editing is one thing, developing is
another.
> For writing letters and
> invitations, and greeting cards a GUI wins you a lot. Being able to see bold
> text on the screen is much better than seeing <bold> tags or whatever. But code
> is just plain old text. There's syntax highlighting but that by definition
> is done by the editor not by the user and is just a display issue and
> vim does colours just as well as anything else...
> >> The phenomenon of masses of volunteers creating
> >> novice-friendly applications for Linux due to altruistic motives or
> >> a desire to see a free software platform succeed is a relatively recent
> >> phenomenon, and the efforts of these intentions haven't been fully
> >> realized yet.
> >
> >Probably because the tools suck!
>
> More likely because it is a new thing, and things take time to get up
> to speed. Until very recently, the vast majority of linux developers have
> been developing for other developers. Other Unix developers...
>
> Also because the people that write the code didn't want them.
I'll bet you that if IDEs were available the users of the IDEs would
eclipse the current handfuls of coders.
> >> Another issue with Unix software is that graphical
> >> apps make demands on the availability of X Windows running and
> >> on bandwidth of a network connection that prohibit work in
> >> many situations, so people typically refrain from doing something
> >> that only pays off in eye candy rather than functionality if
> >> it is going to be useful in fewer circumstances.
> >
> >Yeah right, like people develop over a LAN or WAN. Give me a break.
> >Your child-like resistance is noted in your use of "eye candy" and
> >dropped your case to ground zero.
>
> I have developed code across a telnet session a lot. I use the consoles on
> my linux box as much as I use X (easier on my eyes sometimes). I don't think
> I'm that much of an exception.
>
> I almost always write code over a LAN (seeing thos X Terminals don't run
> anything except X).
All those details should be abstracted as much as possible. Standards
should exist at the lowest levels (like a make std e.g.) to ensure that
vendors aren't able to package low level control in a proprietary format.
> A developer can spend a week writing a GUI or they can spend the week adding
> some other feature to the code. Since they probably have much more training
> and/or experience at coding then designing user interfaces, the most
> efficient choice is not hard for them to see. Plus they have learnt to
> code without a pretty GUI. They see the command line as being more powerful.
> Whether it is more powerful or not is irrelevant. Perception is what matters.
>
> If the GUI can be done quickly by some GUI builder tool. Then the author
> can spend maybe an hour or two doing a GUI, or they can spend an hour
> or two doing something else. A lot of people seem to choose to do
> something else...
It's not finished until the documentation is done and the interface is
done. Basically, the core functionality is just a _beginning_ to a real
product. Most things being heralded here are simply "proof of concept"
things. "Products" entail much more if they are to have mass appeal.
> Ease of use does not mean better. Faster to start with does not mean better.
> The reason 'Windows took over the world' is because it had very good marketting
> and it allowed every day people to use a computer. It made it much easier to,
> for example, create a word processor document. You didn't have to read the
> manual and discover all the strange key codes. You just clicked on the
> menus and icons and stuff.
>
> However, programmers are not every day people when it comes to computers.
> They aren't afraid of braking the computer if they type something wrong. They
> have a better idea of how the things work and so have less to fear. They spend
> their time editing plain old ASCII text and not bold, underlined, coloured
> business reports.
Faulty reasoning. Editing is only one aspect of software product
development. (You know that).
> Unix and linux is a system for programmers to program on. It is not an OS for
> the every day user.
How ironically true!
<snip, how to use command line tools>
> All an IDE would buy me is someone elses ideas for how all my tools should
> be grafted together. I'm happy with my way thanks. All a GUI IDE would buy
> me is the same thing with a restriction that I can't use it on those
> dumb terminals and telnet connections.
That's fine if you're in charge. But a larger standard way of doing
things more productively (rather than everyone inventing their own
environment) is a necessity for commercial work.
> An IDE is a good thing, provided the components are actually seperate
> programs. That way I don't have to learn a new bunch of options and ways
> of doing things for every language or vendor that I use.
I think you have to choose: do you want to be an IDE/environment
developer or do you want to concentrate on developing other products.
> >> This is partly
> >> historical accident (generalizing from the transition
> >> of MS-Dos to MS-Windows), partly socialization (Windows
> >> users are trained to be application oriented rather
> >> than tool and data format oriented and trained to learn
> >> by trial and error rather than by reading documentation),
> >
> >That's not a particular correct way to state it. The fundamental
> >principle is that people can relate to pushing buttons and such just like
> >most can use a stereo system. UNIX, to continue the analogy, is like a
> >stereo system without the front panel and all the circuits exposed: you
> >have to solder something just to turn it on!
>
> A bad analogy really. People can relate to pushing buttons. It only takes
> a little bit of training to learn that typing a command is just the same. I
> click the mouse on my commands - very button like. Unix isn't like having
> to solder, is like having more knobs that do things and less lights that
> show what is happening...
Not many would agree with your obvious contrivation to save the face of
your paradigm. The stereo analogy is close to a perfect one. You like
to solder in the guts of the components while MOST people buy stereos to
listen to music.
> Commands line interfaces give you more control.
GUIs automate repetitive tasks and abstract uneccessary complexity. But
I really don't want to argue CLI vs. GUI with you. I'll just accept that
you are limited by 1970's technology. (Read, no you can't get a job in
my shop).
> yourself by typing words, then by clicking buttons. Most people have two
> arms, which makes it hard to type and press buttons at the same time as well.
>
> I don't care if people can't relate to the development tools I use. All I care
> is that they are the best tools for the job. If a GUI IDE was better I would
> use it (I'm young enough that I used A Mac and Windows 3.1 before I ever
> used Unix), but a GUI IDE is restrictive and it doesn't let me use all the
> knowledge and skill I have using command line tools.
Again, the goal is to focus on products and not the work environment.
You've sacrificed your limited amount of brain ROM to knowing what you
didn't have to (unless you are a tool builder).
> A small tool that does one job well will have less bugs in it than a monolithic
> IDE that does everything. Less interactions between code means less bugs.
Don't build the IDE that way.. just plug in the component tools you need.
What could be easier? That scenario requires standard interfaces is all.
> If you prefer a GUI IDE then by all means use one. I won't stop you. I will
> rant and rave like I have in this post though, since I honestly believe you
> will be more efficient if you use better tools for the job.
Actually, I use that question as an interview question. If you're a CLI
afficionado, I send you on your way. Just my requirements is all. We
automate what we shouldn't be concentrating on on a daily basis here.
> Any function that your IDE does that makes writing code better, my collection
> of tools can do too. If there is something you find amazingly useful, then
> let me know so I can add it to my collection of techniques.
Get an IDE like CodeWarrior or BC++ 5. They show the way at least.
> I've used things other than X. I don't care if X sucks. I use more code than
> I write. If GUIs were better then I would prefer using them. What can a GUI
> do that a CLI can't? Nothing obviously (except draw pretty pictures on the
> screen).
Make developers focus on product instead of the environment they are
working in. Yeah, I guess you're right: we should get rid of all the
robots and automated assembly lines and go back to doing everything by
hand.
> So what does a GUI do that is better than CLI? Other than building another
> GUI (which a GUI system is better for, I'd rather draw my interface then
> write lots of 'new Button()' code).
>
> searching text, replacing text, revision control, building - all
> those things seem to be harder to do with a GUI.
>
> Programming is basically editing text. You don't need a GUI to simply edit
> text. In fact it just gets in the way. At best it just takes up some more
> space on the screen that could contain some more code context.
OK, I get it, you're just starting out and see programming as an end
instead of a means. You _write_ code instead of _build_ product. I see.
Don
------------------------------
From: Albrecht Jacobs <[EMAIL PROTECTED]>
Subject: 2.2.5-ac6 won't boot on Alpha
Date: Fri, 9 Apr 1999 23:14:31 +0200
Reply-To: Albrecht Jacobs <[EMAIL PROTECTED]>
Hi,
I tried 2.2.5-ac6 on our Alpha 21164A/PC164UX2 to solve a problem with
hwclock and xntpd (something with these 'ticks') but it won't boot. This
is what it says during boot (handmade faksimile):
[...]
ncr53c875-0: on-chip RAM at 0xc004000
CACHE TEST FAILED: script execution failed.
start=8001f648, pc=8001f648, end=8001f674
CACHE INCORRECTLY CONFIGURED.
ncr53c875-0: detaching ...
[...]
ncr53c875-0: on-chip RAM at 0xc002000
CACHE TEST FAILED: script execution failed.
start=8001f648, pc=8001f648, end=8001f674
CACHE INCORRECTLY CONFIGURED.
ncr53c875-0: detaching ...
[...]
ncr53c875-0: on-chip RAM at 0x9101000
CACHE TEST FAILED: script execution failed.
start=8001f648, pc=8001f648, end=8001f674
CACHE INCORRECTLY CONFIGURED.
ncr53c875-0: detaching ...
scsi: 0 hosts
scsi: detected
[...]
In consequence the kernel is unable to mount the root partition (which
is on sda2).
Further info needed?
Any ideas?
Albrecht
+-------------------------------------------------------------------------+
| cand. aer. Albrecht Jacobs CAAD-Labor des SI |
| Systembetreuung Universit"at Stuttgart |
| |
| Liegeradgruppe Stuttgart |
| O__ http://www.architektur.uni-stuttgart.de:1200/users/aj/lieger |
| \\_/\-o |
| (+) O [EMAIL PROTECTED] |
+-------------------------------------------------------------------------+
------------------------------
From: [EMAIL PROTECTED] (David M. Cook)
Crossposted-To:
comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.help,comp.unix.programmer
Subject: Re: CodeWarror for Linux (was: Re: Programming tools for ...)
Date: Sat, 10 Apr 1999 00:54:43 GMT
I just wanted to interject into this discussion that there are IDEs for
unix. They range in price from free to "if you have to ask you probably
can't afford it." I have a listing of some at
http://members.home.com/davecook/devel
Dave Cook
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To:
comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.help,comp.unix.programmer
Subject: Re: CodeWarror for Linux (was: Re: Programming tools for ...)
Date: Fri, 9 Apr 1999 18:01:59 -0500
In article <YBtP2.1007$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
> <[EMAIL PROTECTED]> wrote:
> >[EMAIL PROTECTED] says...
> >> <[EMAIL PROTECTED]> wrote:
>
> >> >What I don't understand is why the low level syntax of, say, make hasn't
> >> >been used as a foundation to build upon in an IDE. Most professional
> >> >developers would then use IDEs that are based upon an open standard so no
> >> >proprietary lock-in could occur (many IDEs would be available that
> >> >basically just produce a make file and interface gcc and RCS e.g.).
> >> >Personally, I think UNIX people like things complex for job security or
> >> >some bull like that. Perhaps it just goes back to the failing of UNIX:
> >> >no simple GUI std??
>
> >> I think you are barking up the wrong tree. Let me explain.
> >> Make is used as a foundation for more powerful tools such as
> >> autoconf, imake, automake, etc. These are not GUI tools for an IDE, but
> >> rather character app based tools that get jobs done for people that
> >> need to do them. So the premise that nobody builds on top of make
> >> is for Unix is wrong. The hypothesis that people prefer tools that
> >> are not novice-friendly for job security is also wrong.
> >
> >> It shouldn't
> >> be hard to see that there is going to be a big difference in the
> >> typical style of free software applications that are created or enhanced
> >> by individuals, to personally help them get their work done vs.
> >> the style of a commercial application that is developed by a software
> >> company to sell to the largest number of users.
>
> >That's exactly what's hard to see: why the fundamentals of process
> >improvement haven't been accepted.
>
> There isn't any connection between what I wrote and notions
> of "process improvement". There is a difference in goals
> and available resources.
Sure there is, unless one stagnates a the lowest levels of technology.
OK, substitute "product evolution" and "keeping up with the times" then.
> >> The difference in
> >> motivations and payoffs and intended user community should be
> >> pretty clear.
> >
> >Nope, not at all. How would having a decent IDE hurt??
>
> Don't know about "hurt". There is a cost to create
> it weighed against the benefits it provides.
> If it has high cost to create and isn't as functional
> as, say, Emacs, which already exists, then it is a net loss.
> If it was a lot better in some way then it would be a gain.
Emacs? How could anything be worse?? Guaranteed: if the tools were
better free UNIX would be a lot more accepted. There's still the problem
of obsolete monolithic design of the kernel offerings however.
> >> The phenomenon of masses of volunteers creating
> >> novice-friendly applications for Linux due to altruistic motives or
> >> a desire to see a free software platform succeed is a relatively recent
> >> phenomenon, and the efforts of these intentions haven't been fully
> >> realized yet.
> >
> >Probably because the tools suck!
>
> Now you are just indulging in non-specific ranting.
No, not really. That's a widely accepted assessment that shows the
degree of dissatisfaction and one reason for staying away.
> >> Another issue with Unix software is that graphical
> >> apps make demands on the availability of X Windows running and
> >> on bandwidth of a network connection that prohibit work in
> >> many situations, so people typically refrain from doing something
> >> that only pays off in eye candy rather than functionality if
> >> it is going to be useful in fewer circumstances.
> >
> >Yeah right, like people develop over a LAN or WAN.
>
> Yes, all of the time, and often over modem lines even.
> I have done this many times, and I imagine most Unix programmers
> have as well.
Let's be realistic. "99%" of development is done at a workstation and
just results are transferred back and forth.
> >Give me a break.
> >Your child-like resistance is noted in your use of "eye candy" and
> >dropped your case to ground zero.
>
> Where is all of this flaming coming from?
It's not really flaming, just honest categorization. makefiles, emacs
etc = circa 1979.
> In the first place,
> I am not resistant to IDEs, in the second place "eye candy" is
> not a derogatory term. It's just a short hand for saying something
> that has visual appeal without added functionality.
And then you've missed the most important aspect of computing that
brought mass appeal and accessibility. An IDE makes one almost
immediately a product developer while someone who has to learn the
cryptics of make and emacs isn't even at level zero. And why perpetuate
what is completely unnecessary?
> >> There is one part of the quoted text above that does hit near the
> >> truth, I think - the libraries for creating GUI apps on
> >> Unix were traditionally too hard to use. For example, I recently
> >> worked at a software company where the main development environment
> >> was HP-UX, and I found myself far and away preferring the character
> >> based version of their debugger to the graphical one, even when
> >> I was sitting at an X station, because the character based one
> >> offered more functionality. It was obvious that so much effort
> >> had gone into the initial production of the Motif GUI for the
> >> visual one that access to functionality and bug fixes had
> >> gotten left on, even though the underlying internals of the
> >> debuggers were identical. This library situation is changing
> >> rapidly.
> >
> >Agreed, X sucks.
>
> X is excellent, for the most part. But there needs to be more
> equally excellent software libraries layered on top of it to
> realize its potential.
We'll agree to disagree then. The design of X is as obsolete as
monolithic BSD. They're both monstrosities that hold back innovation.
> >> All of this is just by way of explanation. There are good
> >> reasons to create user friendly GUIs and, ultimately for
> >> IDEs (though many of the reasons are different).
> >
> >Now you're being rational.
>
> Thanks for your approval.
>
> >> But I
> >> think there is also a lot of conditioned bias in people
> >> coming from Windows to think that the more graphical and
> >> integrated apps are more powerful.
> >
> >They are. Instant productivity. It's the basis of why Windows took over
> >the world and why UNIX failed:
>
> I think it has been pretty amply documented that the ability to
> establish a software monopoly on the least expensive commodity
> hardware platform and use economic leverage to force hardware vendors
> of that platform to ship your software preinstalled with every
> machine sold was a primary factor in the success of Microsoft Windows.
Now you're quilty of propagandizing. You forget that MS wasn't always as
powerful as it is today. People (dumb users if you wish, but many others
too) CHOSE the instant accessibility of Windows rather than wading
through the mud of such things as emacs and makefiles (just examples).
> >it was the GUI that made the environment
> >accessible to people who wanted to USE the computer to work rather than
> >work on the computer itself (configuring it etc).
>
> Lots of people used DOS on Intel before Windows, even though it
> was a poor limited environment in almost every way. Why did they
> do that?
Because it was the only thing available.
> Because it has some utility and it was what they could
> afford. Since Linux has made Unix affordable on the cheapest
> hardware it has been growing at an amazing rate - faster than
> MS-Windows. Linux does have a GUI and it could use more polish.
> I don't think there is much disagreement about that.
But sadly, a day late and a dollar short (technologically obsolete, GPL-
afflicted). The hype will subside. Most Linux users are very young
techies.
> >> This is partly
> >> historical accident (generalizing from the transition
> >> of MS-Dos to MS-Windows), partly socialization (Windows
> >> users are trained to be application oriented rather
> >> than tool and data format oriented and trained to learn
> >> by trial and error rather than by reading documentation),
> >
> >That's not a particular correct way to state it. The fundamental
> >principle is that people can relate to pushing buttons and such just like
> >most can use a stereo system. UNIX, to continue the analogy, is like a
> >stereo system without the front panel and all the circuits exposed: you
> >have to solder something just to turn it on!
>
> I don't think that "relate" has much to do with it.
Well don't go jumping all over semantics when I know you knew exactly
what I meant and my example should have clued you in (which you
conveniently ignored so that you could give your following _rant_)
> Rather it
> is the case that menus are a very efficient way to get finite
> choice information from a casual user and GUIs make it particularly
> easy to navigate menus. Also it is convenient to work on
> multiple tasks at once, be able to see those tasks, be able
> to exchange some information between them, and be able to
> display a high density of information at once on a common
> display. For just entering new information and commands
> from a very large set, typing if much more efficient.
> That's why GUI-based editors don't have users
> spelling out words by selecting letters from a menu.
> These are things that are all about functionality and
> not about 'relating'. That said, there is also value
> in having a pleasant environment to look at while staring
> at the screen all day and I don't denigrate that, your
> misinterpretation of my earlier remarks not withstanding.
Again, would you buy a stereo system with no panels, buttons, knobs and
labels on it? The analogy fits almost perfectly.
> >> and
> >> partly the effect of marketing and being used to a world
> >> were mass producers of software that took hundreds of
> >> thousands of person-hours to produce pay for shelf space
> >> at CompUSA to sell their stuff to technoogical illiterates.
> >> I think that both cultures need to work harder to see
> >> the limitations of their own historical experiences and
> >> biases.
>
> >You're in the stone age obviously.
>
> Obviously why?
Because you have not assimilated the evolutionary timeline of human-
computer interaction appropriately.
> >Giving CLI equal credibility in the
> >old CLI vs. GUI debate lessens YOUR credibility for engineering common
> >sense.
>
> Where did I say this. I don't even know what it means.
The "flavor" of your prose resembles to a high degree the "command line
interface" vs. GUI debate.
> Could you state explicitly what it is that you think I claimed?
> I could just as easily make some broad claim like "You have
> no credibility because you discount that value of thousands
> of years of evolution towards sophisticated symbolic languages
> and instead you want to go back to the level of pictorial
> cave painting and pointing with sticks.". But I don't
> think that is what you want, so I won't waste anyone's time
> with such empty rhetorical straw-men.
>
> >Just calling em like I see em.
>
> No, you seem to be just reacting to keywords like some kind of
> behaviorally conditioned animal, without "seeing" anything.
Right back at ya.
> >I think the defensive posture taken by your kind
>
> What in the world are you talking about. What am I supposed
> to be defensive about and who is my kind?
My stance: free BSD UNIXs are lacking the tools to make the OS more
widely accepted. I could add to that that the whole point of building
IDEs for an obsolete architecture is a moot point anyway. You would tend
to think, I believe, that the state of both is appropriate for the
evolutionary timeline of technology. And that's probably as nice as I
could put it.
> >is probably because you
> >just don't have a GUI that is useful or elegant (X sucks) so you have to
> >patronize yourselves.
>
> For the thousandth time, X is not a GUI. It is a graphical device
> interface, like the MS-Windows GDI, except it has the ability to
> be network transparent and portable to more machines.
Yep, all things to all people.. hence it's failing. A HUGE block of code
that is as inaccessible to developers as UNIX is to endusers.
> >the problem is that X
> >means the GUI monolith is more trouble than it's worth because some
> >comittee tried to make it all things to all people (kinda in the style of
> >today's free UNIX?)
>
> This comment bears no relation to any historical reality. Certainly
> fewer people participated in the original design of X than in
> the design of any version of Microsoft Windows.
You're arguing semantics again. The _result_ (X) is a comittee-like one:
a bloated monolith.
UNIX monolith + X Windows monolith = a source code junk yard?
Don
------------------------------
From: [EMAIL PROTECTED]
Subject: scanning scsi-cdrom
Date: Fri, 09 Apr 1999 14:17:15 GMT
Hi,
I've got the problem to scan a whole SCSI-CDROM ( not an audio CD ) without
interruption.
My guess is to either apply one of the READ ( 6,10) commands with a large
Transfer Length or to use the Search Data Command (opcode 30h - 32h).
The first option is limited by "sg.h:#define SG_BIG_BUFF 32768" in the
driver source. This limits me to read only 13 Frames. Of course I can try to
increase this value in the kernel (?).
Anyway, the second way seems to be more promising. But the member of
sg_header structure "sg_hd->reply_len = OFF + out_size" is involved in
allocating scsi-buffer-memory in the kernel. So if it's bigger than
SG_BIG_BUFFER, the command won't work. I wonder if this is ok, because for a
Search Data command you don't need to store the scanned data in the buffer.
On the other side, if I set out_size (or reply_length in the sg_header
structure) to a small value and try to pass the wanted number of sectors for
a search through the SCSI-command block, it doesn't report a memory
allocation error but it still scans for about 1 minute. I don't know how the
SCSI-command block are getting involved by the drivers.
But don't tell me to read the SCSI-Programming-Howto and SCSI-Manuals
please, that's what I've done the last few days...
Sorry, this is a little bit difficult to understand, it needs someone who is
familiar with this problem.
Cheers, Kay
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
