Linux-Development-Sys Digest #500, Volume #6 Wed, 17 Mar 99 16:14:06 EST
Contents:
Re: After Week 1 With Linux -- licking wounds. (Robert Krawitz)
Re: After Week 1 With Linux -- licking wounds. (Bill Anderson)
Re: Device Driver...what for? (Vincent)
raidzz-v0.1.tgz uploaded to sunsite (Gianni Mariani)
Re: kernel (accoday)
problem with mmap of physical memory (pmueller)
Re: Threads and clone() ("B. James Phillippe")
Re: select_wait (Andi Kleen)
Re: After Week 1 With Linux -- licking wounds. (Dale Pontius)
----------------------------------------------------------------------------
From: Robert Krawitz <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.questions
Subject: Re: After Week 1 With Linux -- licking wounds.
Date: 17 Mar 1999 09:33:33 -0500
Darin Johnson <[EMAIL PROTECTED]> writes:
> You're implicitly assuming that no CLI *ever* can go beyond the
> limitations you see now. What if someone said "for a modern GUI, one
> must learn to navigate tortuous menus, know when to use the left,
> right, or middle button, and what keys to push at the same time"?
> It'd be absurd. Yet you're doing the same thing essentially.
Actually, it doesn't seem all that absurd to me. I find a lot of GUI
apps very frustrating to use for precisely this reason. Yes, commands
such as open, save, and such are usually not a problem (but standard
things of that ilk aren't much of a problem anywhere), but more
elaborate things are.
> The best I feel is a cross between the two. It's been done, but few
> have ever tried to do it again. Primarily because it wasn't done for
> novice users, it was done for experts. I'm speaking of lisp machines.
What a wonderful environment. If only such an environment existed
that could run on contemporary processors. I would gladly sacrifice
the kind of performance it would take in order to run that environment
on my PC. Even higher end machines such as the 3670 had processors
and memory that were insignificant compared to any modern PC, and yet
they were quite fast enough.
Emacs (I use GNU Emacs 20.3) has some of the same characteristics.
> Part of the problem with GUI's from my view, is that much of their
> overriding goal is to provide something easy for a novice to use.
> This would seem in many cases to eliminate opportunities for
> non-novice features and interfaces! Ie, look at MSVC++, which is a
> prime example because it's designed for the non-clueless, yet it
> treats them dolts. (on the other hand, with the advent of MSVC 5,
> I can claim that I use Emacs because it's smaller and more efficient :-)
Or this whole notion of an "intuitive, easy-to-use system (or network)
administration environment." What's really meant is "intuitive and
easy to use for a computer novice." This is absurd. Someone with no
experience with computers should not be trying to administer a
computer network. The controls of a Boeing 777 are not designed to be
intuitive or obvious to someone not trained as a pilot of such an
aircraft. If that sort of thing is desired for home use, it should be
a black box that requires no external administration at all (certainly
there are very few home users who should be trying to configure DHCP,
just as an example). For administrators in commercial environments,
the ideal interface is one that is intuitive and easy to use _for an
experienced computer user with a good working understanding of the
systems and infrastructure in use and an understanding of the basic
concepts of system administration_.
GUI's have their place here. For example, a useful network
administration tool might be one that flags various computers or
networks with colors depending upon the state of the appropriate
device. Perhaps all systems that are running well would be marked
green, those that appear to be overloaded yellow, those that appear to
have a problem orange, and those that are not responding or otherwise
in a critical state red. This kind of display would present useful
summary information to the administrator in a form that's easy and
fast for the human brain to process, and would allow the administrator
to quickly take action. But configuration menus out the wazoo for
network addresses and such? This just forces extra work (navigating
through a maze of menus) for something that the administrator knows
like the back of her hand (and if she doesn't, she has no business
being a system administrator).
Good user interface design takes into account the appropriate target
audience, understanding their needs, and develops something that
operates well with the thought and action processes of members of this
audience. Using mice and menus everywhere, even where the concepts
are better handled through text, just gets in the way.
--
Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/
Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
------------------------------
From: Bill Anderson <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.questions
Subject: Re: After Week 1 With Linux -- licking wounds.
Date: Wed, 17 Mar 1999 17:21:04 +0000
Bengt Richter wrote:
>
> On Tue, 16 Mar 1999 17:42:35 +0000, Dr Dale Mellor
> <[EMAIL PROTECTED]> wrote:
>
> >Robert Krawitz wrote:
> >
> >> The Windows find utility is (moderately at best) convenient if
> >> you're doing something it's capable of, but it seems to be very
> >> limited.
> >
> > This line completely sums up the entire Windoze/Mac outlook, doesn't
> >it?
> >
> >Dale
>
> FYI, NT4 has two versions of *CLI* find programs: find, and findstr.
> The latter is a lot more powerful than the original. Both work from
> a command line window:
... (output on commandline for CLI utility in WindowsNT)
> What's missing for my frequent purpose is the ability to output
> before=and/or-after lines of context with the matching lines, (and
> optional blank line separation where contexts do not overlap).
>
> (So I wrote a little kludge to do that, which I use a lot, even though
> mine doesn't do reg exp. Also added @@file-list to use a file list
> with one unquoted filename per line with possible embedded blanks).
>
> Regards,
> Bengt Richter
>
> Added before sending this off:
>
> BTW, if you get the MSW32 SDK, you get qgrep.exe, which is similar
> (copied to clipboard from CLI window, and pasted here):
... (output on commandline for CLI utility in WindowsNT)
> ----
> If you get the resource kit, you get perl and a lot of other goodies.
>
> The thing is, the casual Windoze user will never be aware of the
> extra stuff like qgrep, because he won't get it for free in a
> practically-free "distro" ;-) And there is no findstr icon or
> menu entry, so s/he won't likely know about that either, even
> though it's available and documented in the help.
>
> BTW, NT will let you type "freecell<Enter>" at he command line and
> it will bring up the game -- which is handier than clicking
> start>programs>accessories>games>freecell and scanning all those
> lists with your eyeballs. Of course, you can create a shortcut, or
> an incon right on the desktop, or at the first level of the start
> menu...
Of course, then you have additional effort, and after a short while your
desktop is a collection of shortcuts that you have to scan through as
well.
>
> However: cmd.exe (NT's command.com) is not much better than the DOS
> original (very bad). I don't understand why MS never adopted a decent
> shell. Maybe by the time they were thinking of it, they were doing
> windows and thought a decent shell would slow down the acceptance of
> windows?
>
Most of this post seems to be extolling the command line virtues.
Not sure if that was the intent.
------------------------------
From: Vincent <[EMAIL PROTECTED]>
Subject: Re: Device Driver...what for?
Date: Wed, 17 Mar 1999 17:13:47 +0100
"Caolan (McNamara)" wrote:
> David L. Bilbey ([EMAIL PROTECTED]) wrote:
> : I have recently become interested in writing device drivers, and I know what I
>have to do
> : (thanks to several posts on this ng) to learn how. My problem is, I don't know
>what
> : device I could write a driver for. Everything I own is supported. I would kind
>of like
> : to write a driver for some kind of unique unsupported input device (just a
>thought). Any
> : ideas?
>
> : bilbey
>
> : --
> : "One of the bad things about panning for gold is maybe sometimes you'll
> : get a crawdaddy in your pan, and you start to wonder if you should give up
> : on the gold and just go for crawdaddies. I can't make that decision for
> : you." --Jack Handey
>
> Computer Based Telephony cards, theres a large lack of supported cards
> in this area. On one project that im involved in we had to reccomend
> using solaris rather that linux because there was no support for any
> cbt cards.
>
> C.
>
> --
> Real Life: Caolan McNamara * Doing: MSc in HCI
> Work: [EMAIL PROTECTED] * Phone: +353-61-202699
> URL: http://skynet.csn.ul.ie/~caolan * Sig: an oblique strategy
> Incorporate
I'm looking for some documentation about programming Drivers device and specialy on PCI
hardware.
Have you some source about it for me ?
[EMAIL PROTECTED]
------------------------------
From: Gianni Mariani <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: raidzz-v0.1.tgz uploaded to sunsite
Date: Wed, 17 Mar 1999 19:31:34 GMT
This is the README.
raidzz v0.1
Written by Gianni Mariani
LICENCE MUMBO JUMBO
===================
This is available under the terms of the GNU Public Licence (GPL). Go
fetch yourself a copy.
The author accepts no responsibility at all for any malfunction, loss
of revenue, loss of mental health or loss of anything from anyone
using his software. If you use it, it is up to you to make sure
that the software performs to your expectations. In short, throw me
praise and money, but do not expect anything from me.
INTRODUCTION
============
raidzz impliments a double error recovery algorithm suitable for
use in RAID like error recovery systems. This library could be used
for things other than RAID. A similar concept could be used for tape
drives, where an array of `inexpensive' tape drives are used and
error recovery is performed by having multiple parity tapes.
The word `parity' here is used somewhat incorrectly. The `parity'
here refers to the moral equivalent of what RAID refers to as
parity but it is computed using functions as per the theory described
in the file RAIDZZ.
This scheme seems to impliment the moral equivalent of RAID-6, although
the author is not familiar with the details of RAID-6 implimentations.
If this implimentation is identical, it was coincidnece. The author's
interest is to enable someone to integrate true double redundantcy
error recovery RAID into any OS even though the commercial viability is
somewhat unclear, he believes that there exists people that are as
paranoid as he is and are willing to take the pain for the percieved
gain. Yes the author has had many disk failures and believes they are
out to get him. `they' are little nonobots that go around looking for
his hard drives to trash them.
This library impliments two `parity' buffers. For instance, 10 disk
blocks to be striped over 10 disks could have 8 payload blocks and 2
parity blocks. The error recovery algorithm will be capable of
recovering the loss of any 2 blocks. The tables will allow up to 15
data blocks and 2 parity blocks.
API
---
The basic concept of the API is that the parity buffers are computed
by raidzz_gen_parity() and can be later used by raidzz_recover(). The
API is somewhat general but the valid parameters are limited.
raidzz_gen_parity
=================
#include <raidzz_if.h>
int raidzz_gen_parity(
unsigned int data_mask, /* A 1 bit indicates not
to use buffer*/
unsigned int num_data, /*
unsigned char ** data_table,
unsigned int parity_mask, /* A 1 bit indicates not
to use buffer*/
unsigned int num_parity,
unsigned char ** parity_table,
size_t data_len
);
raidzz_gen_parity will compute the contents of the `parity' buffers
passed in by parity_table. The parity buffers need to be initialized
to zeros.
num_data and data_table indicate the number of data buffers and pointers
to the data buffers respectively.
data_mask indicates that the buffer in the data_table where the
a bit position is set should not to be used to compute of the parity.
This can be used to control how the parity buffer is built.
raidzz_gen_parity can be called repeatedly with the same parity buffers.
num_parity and parity_table indicate the number of parity buffers and
pointers to the parity buffers respectively.
parity_mask indicates that the buffer in the parity_table where the
a bit position is set should not to be used.
Return values:
raidzz_OK (0) Parity was computed
OK
raidzz_ERR_num_parity num_parity is out of range
raidzz_ERR_num_data num_data is out of range
raidzz_recover
==============
#include <raidzz_if.h>
int raidzz_recover(
unsigned int error_mask, /* A 1 bit indicates the
error */
unsigned int num_data, /* Number of data
buffers */
unsigned char ** data_table, /* List of data buffer
pointers*/
unsigned int parity_mask, /* A 1 bit indicates not
to use buffer*/
unsigned int num_parity, /* Number of parity
buffers */
unsigned char ** parity_table, /* List of parity buffer
ptrs */
size_t data_len, /* Length of
buffers */
unsigned int num_error /* Number of errors
being recovered*/
);
raidzz_recover will recover from 1 or 2 errors. error_mask should
be constructed to indicate what buffers have errors. num_error should
also be set to 1 or 2. parity_mask could also indicate which buffer
not to use when recovering from single errors. Double errors require
2 parity buffers.
The recovered data will be placed into buffers that are pointed to
by the respective entries in the data_table. The contents of the
recovered buffers will be destroyed and replaced by the "recovered"
data.
The contents of the parity buffers use to recover data will be
destroyed.
Return values:
raidzz_OK (0) Parity was computed
OK
raidzz_ERR_num_parity num_parity is out of range
raidzz_ERR_num_data num_data is out of range
raidzz_ERR_unrecoverable error is unrecoverable
raidzz_ERR_badparams the parameters passed in don't
make sense
OS KERNEL
=========
The raidzz tables are large, ~73k, and should be placed in non-paged
memory for obvious reasons.
PERFORMANCE
===========
It is inevitable that the performance of a software based dual
redundantcy system will be slower than single redundantcy system
because two parity buffers need to be computed. The computation also
requires a function table lookup while a parity system does not.
However, with faster CPU's and more cache, it is possible to get fairly
good performance. The algorithms in this implimentation are not the
highest performance possible. Loop unrolling and cache blocking would
go a long way to improving it's performance. Some "table" specific
improvements could work. Emperical data suggests that on a 350Mhz
PII, the data througput is about 2MB/sec through the parity generator.
As a guess, parity generation could be optimized to about 6MB/sec
on this kind of system.
The parity functions can easily be implimented in hardware and
conceptually be made VERY fast.
BACKGROUND
==========
This scheme was concieved sometime in 1993. An article was posted by
Gianni Mariani in comp.arch.storage in 1994 with enough details to
build the first engine for raidzz. The raidzz parity tables were
computed by using a brute force algorithm. The mathematical proof
for these formulas is by existance. The tables are limited to 15
channels of data, it is unclear if there exists tables that are
that can handle more than these. It is probable that the tables
in raidzz could handle 7 channels with 3 parity redundantcy, there
was some emperical data that the 15 functions to compute the
second parity are also mutually exclusive although this has not
been confirmed.
A similar concept now dubbed RAID-6 was detailed in 1988 by ???.
This work is unrelated but similar.
Why is it called raidzz ? I originally dubbed it RAID10. Then
it was suggested to be called RAID6 which it is not. So, it's called
raidzz since it will probably be a while before someone calls it
anything. zz is for "snoozzing" wiating for a name. `z' 'z' is
also the sound when two hard drives go "Zap". There are so many
good reasons to call it zz that it has stuck after I changed it
from raid10.
------------------------------
From: accoday <[EMAIL PROTECTED]>
Subject: Re: kernel
Date: Wed, 17 Mar 1999 07:52:29 -0800
You might try reading "The Linux Kernel" at
http://metalab.unc.edu/LDP/LDP/tlk/tlk.html
-Aaron
Eldhose John wrote:
>
> Hi,
> I am new comer to Linux. I wanted to find out how the kernel works,
> so I searched through the source code. But it was an unplesent experince
> I could not find any starting point. Please help me to solve the mistory.
------------------------------
From: pmueller <[EMAIL PROTECTED]>
Subject: problem with mmap of physical memory
Date: Wed, 17 Mar 1999 17:45:04 +0100
Hi,
I use mmap to access physical memory from an isa plug-in card (special
bus adapter). A small test program is running successful (n-times).
The problem is a real-world program (working on the mem). If I start it
once and stop it with Control/C i cannot access the physical memory
again. The mapping ... works without errors, but i can't 'see' the
physical mem (there are some magic numbers on the card).
I have built in an signal handler to unmap the memory. But this doesn't
help.
After reboot everything works well again.
Any idea?
Peter
------------------------------
From: "B. James Phillippe" <[EMAIL PROTECTED]>
Subject: Re: Threads and clone()
Date: Wed, 17 Mar 1999 09:18:59 -0800
On Wed, 17 Mar 1999, accoday wrote:
> Mike Delaney wrote:
> >
> > Now, what I'd like to know is: Are we going to see the threads start sharing
> > the same PID, as the POSIX draft dictates?
> >
> I'd actually like to know when there will be better support for
> debugging multi-threaded apps on Linux. Something the proc-fs on Sparc
> would be great. IMHO, a proc-fs interface for debugging would be better
> than ptrace regardless of multi-threading.
LinuxThreads web site claims that gdb is now thread-aware. I haven't
tested it myself. http://pauillac.inria.fr/~xleroy/linuxthreads/
-bp
--
B. James Phillippe . [EMAIL PROTECTED]
Software Engineer, WGT Inc. . http://www.terran.org/~bryan
------------------------------
From: Andi Kleen <[EMAIL PROTECTED]>
Subject: Re: select_wait
Date: 17 Mar 1999 21:08:40 +0100
[EMAIL PROTECTED] (Wlmet) writes:
> extern inline void select_wait(struct wait_queue ** wait_address, select_table
> * p)
> {
> struct select_table_entry * entry;
>
> if (!p || !wait_address)
> return;
> if (p->nr >= __MAX_SELECT_TABLE_ENTRIES)
> return;
> entry = p->entry + p->nr;
> entry->wait_address = wait_address;
> entry->wait.task = current;
> entry->wait.next = NULL;
> add_wait_queue(wait_address,&entry->wait);
> p->nr++;
> }
>
> In the above code it seems that p->nr must be multiplied by size of a select
> table entry somewhere for the code to work but I don't see this in the code
> anywhere. Does anyone know what is going on here?
No, it mustn't. p->nr is simply the number of wait queue pointers in the
select table. This also shows that Linux 2.0 is incapable to select for more
than PAGE_SIZE/sizeof(struct wait_queue *) fds at once.
-Andi
--
This is like TV. I don't like TV.
------------------------------
From: [EMAIL PROTECTED] (Dale Pontius)
Crossposted-To: comp.os.linux.questions
Subject: Re: After Week 1 With Linux -- licking wounds.
Date: 17 Mar 1999 20:52:05 GMT
In article <[EMAIL PROTECTED]>,
Mark Tranchant <[EMAIL PROTECTED]> writes:
>
> You can't change colour depth though, which you can with MS-Windows (see
> the QUICKRES Power Toy). I use 1024x768 in 8bpp most of the time in
> Windows, but occasionally switch to 640x480 in 24bpp for graphics work
> (1MB video card, you see).
>
But you can start more than one X server, and have them running at
different color depths at the same time. I normally run at 16 bpp,
but sometimes fire up a second X session at 8 bpp for finicky
software.
Dale Pontius
(NOT speaking for IBM)
------------------------------
** 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
******************************
