Linux-Development-Sys Digest #172, Volume #7 Wed, 8 Sep 99 15:14:16 EDT
Contents:
Re: Disk and RAM size for character mode Linux (Frodo Looijaard)
Re: affs freezes kernel 2.2.11 ("Ben Anderson")
Re: IDE for c++ dev?
Re: TAO: the ultimate OS (The Ghost In The Machine)
Re: spin lock (Gerhard Fuernkranz)
Where do I get the man pages that tell about System Calls. ("Captain Panic")
Priorities on IP packets (Fernando Ortega Bellosta)
Re: acurate timing ("Steve D. Perkins")
Finding reserved shared memory ("Norm Dresner")
Re: IDE for c++ dev? (Robert Pluim)
DMA direct to block device buffers? (Mark McDougall)
Re: encripted disk (J.H.M. Dassen (Ray))
rcp: protocol screwup: mtime.sec not delimited (Jerry Natowitz)
interrupt times on SMP pentium, linux 2.2.9 ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Frodo Looijaard)
Subject: Re: Disk and RAM size for character mode Linux
Date: 8 Sep 1999 15:35:49 GMT
In <7r425e$73e$[EMAIL PROTECTED]> "Simon Kwan" <[EMAIL PROTECTED]> writes:
>Hi Greeting,
> Could anyone please comment on the approximate Disk and RAM size for a
>smooth running system with TCP/IP, FTP, Telnet, PPP. The system only need
>character mode (no Window graphics, just the plain old shell).
Server or client?
For a client computer, even a 486/DX2-66 with 8 MB will do. I know, I
have used one myself for quite some time. You'll need a 500 MB harddisk;
don't install any X packages at all (except perhaps a few X libraries
if your distribution links common also-text applications to X).
2.0 kernels typically need less memory than 2.2 kernels.
For a server computer, it depends on the number of clients and the kind
of services. I use the same 486 now as a fileserver, and that works quite
well. I would like a little more memory though.
Of course, it all depends on what exactly you are going to do. If you
often do large compiles, you will want a much faster computer. I did... :-)
Good luck,
Frodo
--
Frodo Looijaard <[EMAIL PROTECTED]> PGP key and more: http://huizen.dds.nl/~frodol
At my homepage you will also find a guide for installing glibc under Linux.
New: Linux hardware monitoring kernel modules (LM78/79/80, Winbond etc.)
------------------------------
From: "Ben Anderson" <[EMAIL PROTECTED]>
Subject: Re: affs freezes kernel 2.2.11
Date: Wed, 8 Sep 1999 14:29:52 +0100
Reply-To: "Ben Anderson" <[EMAIL PROTECTED]>
AFFS is broken in 2.2.11, the Amiga disk partition support will hard lock
your
kernel at boot time.
If you've had that HD in a win9x/nt machine then the rigid disk block will
have
been semi-trashed (read affs.txt in the kernel source documentation for a
more
in depth explanation), however your 2.0.36 kernel should still mount it
fine.
Benny
<[EMAIL PROTECTED]> wrote in message news:7qm5u6$ldv$[EMAIL PROTECTED]...
> Hi!
>
> My 2.0.36 kernel mounted my Amiga-hd with no problems the first time,
> but when I moved back to the Amiga, the Amiga couldn't detect the
> ffs-partitions on the drive at all!!
> I did not umount the drive when I shut down the PC, I just took a
> shutdown -hn now. I took the drive back to the PC, and then I just got
> an error message telling that there is a bad superblock on drive
> /dev/hdb1 (maybe you're trying to mount an extended partition inside??)
>
> So, I'm not sure how safe it is to mount the Amiga-HD in Linux yet ..
> but maybe the AFFS support is better in 2.2.11?
>
> file://ZnowbaLL [EMAIL PROTECTED]
>
> In article <9Ptu3.1199$[EMAIL PROTECTED]>,
> root <[EMAIL PROTECTED]> wrote:
> > Has anyone had any luck mounting an Amiga ffs disk with any Linux
> > kernel? While I was picking goodies in the 2.2.11 kernel to enable, I
> > decided to try adding affs, since I have a couple of Amiga formatted
> > zip and syquest disks I'd like to access. Whether I use affs as a
> > module or directly compiled in, as soon as I try
> > mount -t affs /dev/sdb1 /mnt/azip
> > I get something like
> > RDSK sd(blur)(blur)(blur)
> > with the first blur apparently being letters a through o, and the
> > other blurs being digits 0-1 and 0-9. Since my Advansys SCSI
> > controller works fine with VFAT, DOS, HFS, and the usual EXT2 disks,
> > I can't imagine that this nonsense is. What's expecially vexing is
> > that it locks the system up so hard, I have to hit the HW reset.
> >
> >
>
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: IDE for c++ dev?
Date: Wed, 08 Sep 1999 13:32:19 GMT
In article <[EMAIL PROTECTED]>,
Toby Haynes <[EMAIL PROTECTED]> writes:
> Warren Young <[EMAIL PROTECTED]> writes:
> Well - I'd disagree about the way you describe "intuitive". To me an
> editor is intuitive if by knowing the basic manipulations and commands
> of the editor, I can find out how to do things by making a guess about
Oh well, here goes, ;-) From what I have heard, emacs is a VERY powerful
editor, however, most of us will never know because we would rather pay
a few hundred dollars and get a perhaps almost as powerful editor that
one can actually use. Personally I have messed with emacs a few times
and I admit each time I can get a little more out of it than before. For
example I can (I think) reliably open and save a file in emacs! ;-)
Nonetheless, emacs is certainly the MOST cryptic and difficult piece of
software that I have encountered in my 14 years of programming. So
be it, plenty of people have testified that they find emacs to be
well worth the time it took to learn to use it. What puzzles and
bothers me is why SO many emacs fans bristle and shout otherwise when
ANYONE states the obvious, that emacs is EXTREMELY difficult to use.
They remind me of republicans trying to justify the drug war. ;-)
Some things are simple facts, and by denying that emacs is extremely
cryptic, you are simply destroying your own credibility and doing NOTHING
to win people over to the use of emacs. If you like emacs, use it, I am
SURE it is a very powerful editor. But why in the world do you
attempt repeatedly to deny that it is also an extremely cryptic
editor, when virtually ANYONE who has attempted to use it can see
otherwise?
Peace
Peter
Please do not respond to the above address. It is a spam trap
and NO human will ever read it!
------------------------------
From: [EMAIL PROTECTED] (The Ghost In The Machine)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: Wed, 08 Sep 1999 15:46:03 GMT
In comp.os.linux.advocacy, Nicholas Dronen <[EMAIL PROTECTED]>
wrote on Wed, 08 Sep 1999 01:26:25 GMT <5XiB3.394$[EMAIL PROTECTED]>:
>EdToy ([EMAIL PROTECTED]) wrote:
>: In article <7qvj4a$[EMAIL PROTECTED]>,
>: [EMAIL PROTECTED] says...
>: > note above I did not declare anything "true by fiat". I proposed
>: > an alternative to existing dogma & conventional wisdom. I am
>: > saying, "imagine a universe exists in which you are not confined to
>: > the boxes you now believe you are confined within"<g>
>
>: Well don't let your head swell up too much because almost any comp sci
>: student could have come up with (and they probably have) with your subset
>: of suggestions (and many others too). You may think that you're thinking
>: "outside of the box" but indeed you've simply followed obvious paths of
>: the "existing dogma & conventional wisdom". You may have done some
>: _extrapolation_, but I'd have to read your ideas again to be sure. If
>: you want to "see" outside of the box, you'll have to step back a "wee"
>: bit further. Again, I believe the proof is in the doing, not in the
>: dreaming, and using that experience to _develop_ your preliminary ideas
>: into a vision. Not that dreaming doesn't have any merit, just that it's
>: on par with masturbation.
>
>Where's the proof that your Panglossian CreateProcess is better than fork?
>From the peanut gallery:
I could see scenarios where a (theoretical) CreateProcess(),
which specifies the program, arguments, uid, attaching terminal,
and root directory, may be useful as an atomic, consistent process,
in a limited sort of way. However, I also have to state that one
can easily go overboard with this sort of thing. I suspect that
that's what happened with CreateProcess, in its formative stages.
For completeness, here is a copy of CreateProcessA from Borland C++'s
include files (4.51):
WINBASEAPI
BOOL
WINAPI
CreateProcessA(
LPCSTR lpApplicationName,
LPSTR lpCommandLine,
LPSECURITY_ATTRIBUTES lpProcessAttributes,
LPSECURITY_ATTRIBUTES lpThreadAttributes,
BOOL bInheritHandles,
DWORD dwCreationFlags,
LPVOID lpEnvironment,
LPCSTR lpCurrentDirectory,
LPSTARTUPINFOA lpStartupInfo,
LPPROCESS_INFORMATION lpProcessInformation
);
That's right...10 arguments! The SECURITY_ATTRIBUTES structure
introduces another 3 (a DWORD, a LPVOID, and a BOOL), and
the STARTUPINFO introduces another 18 (no, I won't enumerate them
all here!). I'm not sure if PROCESS_INFORMATION is returned,
or read in -- but that's only 4 fields, either way.
This is a total of 38 "fields" (loosely defined as a void *,
a char *, a boolean, a word, or a dword), just to create a process.
And then there are the flags, which I have not specified here
(which enums are appropriate for dwCreationFlags?).
Yipes. I hope the documentation is accurate!
I think all will agree here -- even the Windows zealots -- that this
is a rather confused and confusing API; the creator apparently either
didn't bother to create a single "create process" packet (structure),
or liked the idea of optional pointers (I can't tell without more
documentation on CreateProcess()) to return data that may or may
not be of interest to the caller, or the specification of information
that is non-critical or easily defaultable. I can't criticize the
developer of this routine too roundly, as it's nice to have such a
degree of control (and elicits memories of SYS$SPAWN(), if I remember
it correctly, from my VMS days), but it does mean a little more work
on the part of the developer who uses this particular procedure call,
to understand it, and write calls to it.
Contrast this with system(), which has only 1 argument: the
command string. A far simpler API, if a slightly more complex
and less controllable mess underneath (and there are some issues
with '&' and redirection which may not be obvious to the casual user --
zombie processes may result) -- but then, fork() can be used for
more specialized uses, especially if one wants to use SIGCHLD.
To be fair, fork() has to manipulate quite a few things in
'current' (a pointer to a task_struct); this structure is defined
in /usr/src/linux/include/linux/sched.h, and contains 92 fields (!),
if I've counted correctly. However, this structure is not
user-visible (at least, not in the sense that the user can
easily get at (all of) it through an API [*] -- of course, I can read it
from the Linux source code without difficulty :-) ).
Certainly, fork() is relatively easy to implement -- I suspect that
the original implementer thought it a neat hack :-) -- even given
those 92 fields, and CreateProcess() can be implemented using fork(),
seteuid() and setegid(), execlp(), chdir(), fdup()/fdup2(),
and other routines.
(I will merely mention the vfork()/fork() controversy; vfork()
suspends the parent process as it borrows the vpages from it until
exec() releases them, and reanimates the parent; older virtual
page management meant a speed improvement, but current systems
suffer little, if any, from the code page sharing. Linux also
implements vfork().)
Linux also introduces clone(), which is one of its contributions
to threading; this also calls do_fork().
The meat of all this is of course do_fork().
The 2.2.10 implementation of do_fork() takes 164 lines, not counting
subroutines such as exit_files(). This is non-trivial,
but not too hard to wade through (I've written worse! :-) ),
and probably has mostly to do with the manipulation of the
92 fields (which, in a properly-developed C++ app, wouldn't be
much of an issue, as the task_struct would become a full-fledged
class which would know how to clone itself properly).
(Curiously, sys_fork() in the i386 or alpha architecture doesn't call
lock_kernel() prior to do_fork(), but the arm variant does.
Is this a bug or a feature? :-) )
[*] sys_geteuid() [the kernel hook for the user-level geteuid()],
for example, returns current->euid -- a part of the task_struct.
A number of fields in task_struct are accessible in this manner.
--
[EMAIL PROTECTED] -- "Kernel source? What kernel source?"
------------------------------
From: Gerhard Fuernkranz <[EMAIL PROTECTED]>
Subject: Re: spin lock
Date: Wed, 08 Sep 1999 14:52:57 +0200
Josef Moellers wrote:
...
> Generally speaking, all components of the kernel which modify some
> globally accessible resource have to protect these accesses by some kind
> of locking. In addition, all components that have read access to these
> resources and require these read accesses to be consistent across an
> instruction boundary (i.e. you read twice and need these two accesses to
...
I know about SMP locks and what they are good for.
But I've lost the overview which kernel components/modules
are using which lock granularity (global lock vs. spinlocks).
As far I can remember older Linux SMP kernels used a global
lock only. In the mean time there exist spinlocks too.
But when I look into misc. source modules I see some modules
that use spinlocks, while other modules don't do so.
So I'm wondering which lock granularity to use where in the kernel?
(E.g. it seems that the networking code uses high granularity
(-> spinlocks), but on the other hand some, but NOT ALL network
drivers do :-?)
Gerhard
------------------------------
From: "Captain Panic" <[EMAIL PROTECTED]>
Subject: Where do I get the man pages that tell about System Calls.
Date: Wed, 8 Sep 1999 09:52:49 -0400
I have RedHat 6.0 and I am looking for the man pages that tell about all the
system calls such as "man 2 intro" and "man fork", etc. Any know what this
package is called and or where I can get it? Thanks,
Bri
------------------------------
From: Fernando Ortega Bellosta <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.networking
Subject: Priorities on IP packets
Date: Wed, 8 Sep 1999 18:12:18 +0200
Does any one know if there is something implemented to deal with, IP
priorities in Linux, for example voice over IP.
I know that in the networking source code , it is supported a bit part of
it but it is not enough to guaranty , voice transmition.
In the source code you can only find three priority queues per device, but
what happens if for example I am sending something of priority "2" and
suddenly I have to send something of priority "1", It seems that until the
queue of priority "2" is not emptied (dev_tint), it will not deal with the
priority "1".
I am working on it , and I wonder if you can help me with any info you
know. I need to know how Linux Networking deal with IP priorities, it is
quite difficult( at least , it is for me) to figure it out, just following
the source code.
Any help or collaboration will be more than wellcome.
If you are interested in working on it let me know.
Thanks a lot.
--
Fernando Ortega Bellosta
[EMAIL PROTECTED]
------------------------------
From: "Steve D. Perkins" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux,comp.os.linux.misc
Subject: Re: acurate timing
Date: Wed, 08 Sep 1999 12:03:56 -0400
> Is it possible to know the time spent by a process into the processor
> with a better accuracy than jiffies (100 jiffies in one second)?
I hate to sound ignornant, but is that REALLY a technical
term?!? I had always thought that a "jiffy" was just slang for a
very quick period of time....
Steve
------------------------------
From: "Norm Dresner" <[EMAIL PROTECTED]>
Subject: Finding reserved shared memory
Date: 8 Sep 1999 14:33:08 GMT
System is a P233MMX w/128 MB ram running Red Hat 5.2 with the Real-Time
Linux 0.9J patches. I'm using the append="mem=XXXm" line in lilo.conf to
prevent linux from using all of conventional RAM so I can create a shared
memory area within which both normal user processes and real-time processes
can communicate.
This works. But my problem is to be able to dynamically find the start of
the reserved area on a number of systems, not all equal, without parsing
the lilo.conf file.
I thought of using /proc/meminfo but I'm getting confusing results as
follows:
mem=XXXm MemTotal
124 123776
123 122764
122 121756
The difference between the MemTotal for 124 and 123 is 1012 Kb and between
123 and 122 it's only 1008 Kb. Neither of which is the 1024 kB that I'd
expect.
So, the question is, from MemTotal (or anything else), how can I reliably
find the start of the reserved memory area (assume the program will only be
run on a system which has such a reserve)?
Any and all suggestions, hints, pointers, URLs (and even constructive
flames) are welcome.
Thanks
Norm
------------------------------
From: Robert Pluim <[EMAIL PROTECTED]>
Subject: Re: IDE for c++ dev?
Date: 08 Sep 1999 14:21:27 +0200
Warren Young <[EMAIL PROTECTED]> writes:
> > Maybe there could be an effort to create an even simpler starting menu set
> > for people completely new to Emacs, or maybe this already exists? If
> > not, it probably should be done to increase the number of converts! :-)
>
> What we need is a tool that presents common configuration options in
> menu or list form. And I mean detailed configuration: how the font-lock
> modes colorize source code, what the tab stops are set to, what C-h is
> mapped to, etc. Ideally, this tool will be accessible from the main
> xemacs menus.
Something like, ooh, Options -> Customize perhaps?
--
The above are my opinions,
and my opinions only.
------------------------------
From: Mark McDougall <[EMAIL PROTECTED]>
Subject: DMA direct to block device buffers?
Date: Thu, 09 Sep 1999 00:47:23 +1000
Hi Gurus,
I'm writing a block device driver for a PCI-based storage device. The
device incorporates a bus-mastering DMA engine. Basically I have a
rudimentary version of the driver working, but it's currently
double-buffering all device transfers by DMAing into/out of a buffer
alloc'ed with __free_page(), and using memcpy() to transfer to/from
CURRENT->buffer.
Is there a means by which I can DMA directly to/from the system buffers
passed into xxx_request() (ie. CURRENT->buffer)? All examples that I've
seen of DMA (including Rubini) appear to be ultimately passing data back
into user space, hence the need to allocate a non-cached DMA buffer.
If it *is* at all possible, I of course need to know the physical
address(es) of the (possibly non-contiguous?) pages that comprise the
buffer!!! How do I do this - and what can I assume? BTW my DMA engine
has scatter/gather so I can handle a non-contiguous buffer without too
much trouble.
Also, regarding 'readahead' - are accesses to my device *guaranteed* to
be exactly this size (I'm guessing *NOT*), or how about aligned to this
granularity on the device (again, I'm guessing NOT, though it'd be
*really* nice).
Regards,
--
| Mark McDougall |
| [EMAIL PROTECTED] |
| http://www.zeta.org.au/~msmcdoug |
| Technetium Development Pty Ltd | "Electrical Engineers do it
| [EMAIL PROTECTED] | with less resistance!"
------------------------------
From: [EMAIL PROTECTED] (J.H.M. Dassen (Ray))
Crossposted-To: comp.os.linux.misc,comp.os.linux.setup
Subject: Re: encripted disk
Date: Tue, 7 Sep 1999 21:12:19 +0200
Camil Coaja <[EMAIL PROTECTED]> wrote:
>I would like to protect the data on a removable hard disk against
>unauthorised acces from persons who might get phisical access to it.
>
>Is there a way to transparently encript the data writen and decript the
>data read from the drive in question?
Yes. I've found the international kernel patch (http://www.kerneli.org/) to
be quite convenient.
HTH,
Ray
--
Ray Dassen <[EMAIL PROTECTED]>
------------------------------
Subject: rcp: protocol screwup: mtime.sec not delimited
Reply-To: jin at spdcc dot com
From: [EMAIL PROTECTED] (Jerry Natowitz)
Date: Wed, 08 Sep 1999 12:23:44 GMT
I'm getting this message:
rcp: protocol screwup: mtime.sec not delimited
whenever I attempt to use rcp from one Linux (Slackware 4.0 with kernel 2.2.12)
system to another. .rhosts and inetd.conf aare setup okay, because an
rsh between the two systems works fine.
--
Jerry Natowitz - jin at spdcc dot com
------------------------------
From: [EMAIL PROTECTED]
Subject: interrupt times on SMP pentium, linux 2.2.9
Date: Wed, 08 Sep 1999 17:51:16 GMT
Wed Sep 8 11:12:55 MDT 1999
Jung Pyo Hong, kk5rg
The following are results of measuring the self interrupt times and
other-cpu interrupt times on a SMP machine.
The scull device driver by Rubini for linux 2.1 was modified to
run on linux 2.2.9 and then an ioctl command was added to access
each RTS (real-time-stamp) register on each processor.
The mother board is a TYAN-THUNDER 100 and the cpu inforamtion
is listed below.
========================================================================
When the machine is relatively idle, then the self interrupt time
is about 4 microseconds with sigma of about 0.12 microseconds
and interrupting another processor is about 0.06 microseconds with sigma
of about 0.004 micro seconds.
When the machine was busy, the self interup time was about 4
microseconds with sigma of about 0.2 microseconds and interrupting
another processor took about 6 microseconds with sigma of
0.2 microseconds
Conclusion:
Linux 2.2.19 can be use in sub millisecond real-time applications.
Even when the processors are busy, the RTS is accessable within a
few microseconds. Maximum access time was about 66 microseconds.
When the processors are idle, the access is in the order of
70 nanoseconds. Maximum access time is about 22 microseconds.
========================================================================
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 5
model name : Pentium II (Deschutes)
stepping : 2
cpu MHz : 400.912285
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
sep_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 mmx osfxsr
bogomips : 399.77
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 5
model name : Pentium II (Deschutes)
stepping : 2
cpu MHz : 400.912285
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
sep_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 mmx osfxsr
bogomips : 400.59
=======================================================================The
machine was kept busy with two find commands:
% find /
% find /
========================================================================
Self intrrupt time for the case where cpu 0 caused the interrupt:
number of samples = 8100
minimum = 3.49749755859375
max = 8.864990234375
average = 4.01253547951027
estimate of sigma = 0.182655670602777
Self intrrupt time for the case where cpu 1 caused the interrupt:
number of samples = 1900
minimum = 3.40750122070312
max = 6.0574951171875
average = 4.0567279373972
estimate of sigma = 0.199474075116999
For the case where another cpu caused the interrupt, for 0:
number of samples = 1900
minimum = 0.002471923828125
max = 61.6675109863281
average = 6.32677096718236
estimate of sigma = 0.280737314719782
For the case where another cpu caused the interrupt, for 1:
number of samples = 8100
minimum = 0
max = 65.4674987792969
average = 5.75675787278164
estimate of sigma = 0.13197268268637
========================================================================
The machine was quiet, execpt for the test program.
========================================================================
Self intrrupt time for the case where cpu 0 caused the interrupt:
number of samples = 8046
minimum = 3.61001586914062
max = 5.62249755859375
average = 4.02442388608033
estimate of sigma = 0.105186886704492
Self intrrupt time for the case where cpu 1 caused the interrupt:
number of samples = 1954
minimum = 3.6724853515625
max = 7.6300048828125
average = 4.02662972613269
estimate of sigma = 0.130930225975969
For the case where another cpu caused the interrupt, for 0:
number of samples = 1954
minimum = 0.002471923828125
max = 7.72000122070312
average = 0.0684969071356032
estimate of sigma = 0.00783966348855205
For the case where another cpu caused the interrupt, for 1:
number of samples = 8046
minimum = 0.002471923828125
max = 9.70748901367188
average = 0.0549642746347176
estimate of sigma = 0.00202364283121984
========================================================================
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
** 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
******************************
