Linux-Development-Sys Digest #112, Volume #7 Thu, 26 Aug 99 13:13:56 EDT
Contents:
Re: where are packets created? (Peter Samuelson)
Re: PROPOSAL: A secure, simple NIS replacement (Peter Samuelson)
Re: Linux on embedded systems: question on memory footprint (Steve Houseman)
Re: TAO: the ultimate OS (Donal K. Fellows)
Re: Jesus: the ultimate OS (Peter Samuelson)
Re: Linux on embedded systems: question on memory footprint (Steve Houseman)
How to debug a cross-compiled binary using GDB ? ("Lim, Sung-taek")
Re: Jesus: the ultimate OS (James Andrews)
Edquota.c ("SSonic")
Re: The optimization debate (was: why not C++?) (Paul D. Smith)
Re: Netgear FA310TX (Eric Wampner)
Multipoint protocol? (Pablo Yaggi)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: where are packets created?
Date: 26 Aug 1999 05:08:40 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Yung-Hsiang Lu <[EMAIL PROTECTED]>]
> Where are network packets created? Is this protocol specific?
Which layer do you refer to by "protocol"?
> When I ftp a large file, is it divided into small pieces (I guess
> so). Is this the responsibility of ftp or the device driver? Is
> there a study about optimal packet sizes? What are the typical
> packet sizes? How about http for a large gif file?
Way outside the scope of this or indeed any newsgroup. What you are
asking for is an entire tutorial on network routing ... rather like
going into comp.lang.c and saying "What does 'scope' mean? Do scoping
rules depend on the language?"
I saw a book the other day, "Routing TCP/IP" published by Cisco for $70
or so. It was about three inches thick. And that presumably only
covers TCP/IP (which admittedly probably has the most complicated
routing semantics of any protocol in common use). In short, not the
sort of stuff people will likely type up for you on a newsgroup.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: comp.security.unix
Subject: Re: PROPOSAL: A secure, simple NIS replacement
Date: 26 Aug 1999 05:13:58 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Tuomo Pyhala <[EMAIL PROTECTED]>]
> Depending on the systems mentioned above, one might be able to
> convert the database to such form. I would suppose that normal unix
> user-database would be rather easily convertable into nis-database or
> ldap-directory data. Kerberos would tougher.
The real problem is not converting /etc/passwd to another database form
but converting it *back*, i.e. either getting applications to use the
other form or having a mechanism to regenerate /etc/passwd on demand on
all your machines. libc has directly supported NIS for ages but the
others would require either patches to all your applications or patches
to a common library. This, of course, is PAM's raison d'�tre....
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Steve Houseman)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.help
Subject: Re: Linux on embedded systems: question on memory footprint
Date: Wed, 25 Aug 1999 20:22:56 +0000
Emile van bergen <[EMAIL PROTECTED]> wrote ...
<snip>
>The whole shebang is _mmap()'ed_, not allocated in real memory and
>loaded from disk. So as soon as you use a function whose page(s) are not
>in core, its page(s) are read from disk, but only then. If your memory
>gets exhausted, the RO pages are simply discarded (why swap them, if the
>source of the information is already on disk?), and the dirty RW pages
>are swapped out.
>The RSS is the size of the image which is in core. So it may indeed well
>be much less than the whole libc. For example, if you'd just call
>printf(), it would show only the pages used by printf() code and
>data.
Thanks for the explanation .
>>So if you have a small app not linked with other code
>>and which only used a small seg of lib c , then could
>>extract the bits from the libc source and compile them,
>>and link them as above .
>Why? Remember, Linux is a virtual memory system. It won't help you all
>that much, except the overhead in case the used code is only 10 bytes,
>then you'd waste 4096-10 bytes of physical memory.
This was for the original poster's embedded system where he was
complaining about the amount of memory used for a trivial appn,
and I assumed (probably wrongly) that he might be able to make do
with only a small piece of libc functionality eg say less than 10
functions (open,write,close?) ??
But you are obviously right for a normal system
<snip>
>A real bad 'real' unix that would be, one that pages out an executable
>that's ready to run (zz6 contains a busy wait loop, doesn't it?).
I would expect that it to keep the "active set" and page the rest out
so the loop would be kept in and the rest eg the unused lib stuff
including exit would be paged out .
<snip>
Thanks for responding and your explanation, info and thoughts.
Cheers,
Steve Houseman
--
currently steve.houseman at virgin net
------------------------------
From: [EMAIL PROTECTED] (Donal K. Fellows)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 26 Aug 1999 10:18:29 GMT
In article <7punii$[EMAIL PROTECTED]>,
Vladimir Z. Nuri <[EMAIL PROTECTED]> wrote:
> ah, but surely we can assert that the more brilliant & visionary the
> design, the more difficult it is to pull it off, typically.. not so
> much because of the code, but because of the psychological
> resistance to it. I tend to agree that it will be both easy and
> hard. hard, to get people to agree on the vision. easy, once people
> see the vision. an appropriate taoist paradox.
We see a bunch of known hard/intractable problems.
We see a truck-load of management-speak.
We see bugger all in the way of implementation skeleton to help
convince us to put in the amount of effort required to implement what
you are calling for.
We don't feel very convinced.
Saying "it is difficult to pull off, so it must be right" doesn't cut
it. It wouldn't cut it even if it was made of moonshine, Microsoft
promises and Saharan mist. Come up with at least a better promise of
things to come (just sticking some more flesh on the skeleton would
help a lot) or you'll be relegated to the already-overfull ranks of
the great Internet unwashed.
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ [EMAIL PROTECTED]
-- The small advantage of not having California being part of my country would
be overweighed by having California as a heavily-armed rabid weasel on our
borders. -- David Parsons <o r c @ p e l l . p o r t l a n d . o r . u s>
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: Jesus: the ultimate OS
Date: 26 Aug 1999 05:17:28 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Miles Bader <[EMAIL PROTECTED]>]
> Love is a snowmobile racing across the tundra. Suddenly it flips over,
> pinning you underneath. At night the ice weasels come. --Nietzsche
Someone else's sig, somewhere, attributes this quote or one very like
it to Matt Groening [of Simpsons fame]. Who's right?
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Steve Houseman)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.help
Subject: Re: Linux on embedded systems: question on memory footprint
Date: Wed, 25 Aug 1999 20:16:56 +0000
Dan Mills <[EMAIL PROTECTED]> wrote ....
>What actually happens is that when the function in the library is
>called for the first time a page fault is generated and the page
>containing that function is mapped into your processes address
>space. This may involve loading the page off disk or may simply
>involve setting up a shared read only (copy on write) mapping. It
>is not normal for the whole libc to be in ram, and it would be very
>uncommon for any one task to map the whole thing into its address
>space. It does however mean that the smallest unit of memory that is
>mapped into any process address space is one page (4KB on X86)
so presumably the data is handled in a simlr way (to the code)
ie the page is allocated but not filled , and when the data is
read (or written) then the page is created.
>For ELF files the RSS is:
>Code + Data + Stack + Shared pages!
Thanks for this info ... applying it crudely to the measurements for
the two versions of code, one linked to the lib and tother not,
PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND
1505 steve 16 0 188 188 136 R 0 46.4 0.4 0:02 zz6
1523 steve 17 0 12 12 4 R 0 33.0 0.0 0:01 zz6
so subtracting the share(136) from the rss(188) -> for the lib linked
version gives 52 which presumably is the code + data + stack
ie non-shared ..
so if the code + data +stack for non library version is 12 (?) then
the implication is that 40 is for the library data private to
the appn ? see later ...
>> So if you have a small app not linked with other code
>> and which only used a small seg of lib c , then could
>> extract the bits from the libc source and compile them,
>> and link them as above .
>You can also make syscalls without going through libc
>(trap through 0x80).
Given my current state of assembler knowledge, this was not an option
that I feel comfortable with but is probably the best suggestion
for some one doing this seriously - like the original poster ?
<snip>
>> Just experimented with an extended sleep , and run up a few
>> netscapes so am using 20Mb of 100Mb swap partition and left
>> running for a while, but the RSS size of zz6 does not come down
>> and I dont believe that it is using actively 192 kb ...
>> on a real unix <ducks> this would have disappeared ie would
>> have been paged out and the RSS value would have gone
>> almost to zero ...
This comment was based on memories of work I did (mainly) on aix
where when the system was put under heavy load, paging took place for
some seconds until the unused pages were paged out and only
the active set left ... fascinating to watch (sad person that I am).
> The RSS size indicated for an ELF binary includes the shared library
> pages mapped to that process, as most of that 192KB is probably
> shared with netscape, X, WM.... (It is probably shared C library),
> it cannot be paged out because other apps are using it.
> Note this does not mean that sleep is 192K!!!!
Sorry I used slightly different figures here, but taking my earlier
ones, if my calcs above are right (??) then presumably the 40
should have paged out ?
>> so linux does not seem to do its
>> paging correctly (or at least the same as other unices ... pity).
> Linux pages just fine, but RSS for an elf binary means somthing
> different to what it means for an a.out binary.
>Hope this helps.
>Regards, Dan.
>--
>The email address **IS** valid, you do **not** need to remove spamblock!
>And on the evening of the first day the lord said....
>... 'LX 1, GO!!' and there was light!
It often feels like my brain has inbuilt paging - the more I learn
the more falls out the other side , but unfortunately it gets paged
to /dev/null rather than a recoverable partition :-(
Thanks for responding and your explanation and info .
Cheers,
Steve Houseman
--
currently steve.houseman at virgin net
------------------------------
From: "Lim, Sung-taek" <[EMAIL PROTECTED]>
Subject: How to debug a cross-compiled binary using GDB ?
Date: Thu, 26 Aug 1999 20:33:07 +0900
Hello, I have builded gcc, glibc and gdb as arm-targetted and
i686-linux-hosted.
When I execute gdb to debug a cross-compiled binary and type 'run', gdb
complains that "You can't do that without a process to debug".
In my humble opinion, gdb couldn't execute arm-targetted binary on i686
machine and probably I need a arm simulator or arm board connected to PC.
I think "target sim" has something to do with it. But I can't find any
information
about "target sim". Can anyone help me or advice me what to do?
Thank you in advance.
--
Lim, Sung-taek
[EMAIL PROTECTED]
http://poppy.snu.ac.kr/~totohero/
------------------------------
From: James Andrews <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: Jesus: the ultimate OS
Date: Thu, 26 Aug 1999 13:30:18 +0000
Reply-To: [EMAIL PROTECTED]
Being an open-minded person with athiestic qualities, this sounds like a
discussion I can really get my teeth into, but I wont. This message is
just to ask, are you sure you aren't examining this metaphor a little
too close?
James
P.S: Read athiest as accepting of the possibility of a "god", but not
specifically believing such an existance. Acceptance that the chances
of a "god" like figure existing is a small possibility within an
infinite scope, merely treating life as a journey through which
sometimes there just is no simply defined boundary.
------------------------------
From: "SSonic" <[EMAIL PROTECTED]>
Subject: Edquota.c
Date: Thu, 26 Aug 1999 16:13:16 +0200
Does anyone have the source code for edquota or knows where to get it ?
Thanks
------------------------------
From: [EMAIL PROTECTED] (Paul D. Smith)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: The optimization debate (was: why not C++?)
Date: 26 Aug 1999 10:50:58 -0400
Reply-To: [EMAIL PROTECTED]
%% [EMAIL PROTECTED] (Randall Parker) writes:
rp> I would argue that good coding styles, once one has internalized
rp> them, are not much if any additional effort to practice. So why
rp> not do them everywhere?
My argument is that (a) just because a particular idiom, like counting
down instead of up, gives better performance in some cases it probably
won't in all cases: that's extremely compiler and architecture dependent
and _normally_ I don't think programmers should spend time worrying
about the system on this level, as it leads to bad habits, (b) even
where it does help, it likely won't make a noticeable difference, and
(c) you can't figure out where something like this _will_ make a
noticeable difference until you run the code and see where it's spending
it's time. The primary result I took away from the paper I mentioned on
profiling ("News Need Not Be Slow") is that you can almost never guess
exactly where your program will spend it's time... so don't. Profile it.
I think we're actually almost in agreement.
For example, I completely agree with you that all optimization shouldn't
be left to the end: that is, _macro_ optimizations, or optimizations of
high-level algorithms, should obviously be considered up-front. But
that's a much harder thing to do, and I think many programmers
substitute _micro_ optimizations instead, and feel like they're
accomplishing something.
I don't believe micro-optimizations buy you much at all, generally, and
they often take longer to program, have more bugs because they're more
complicated than they need to be, and are harder to read, understand,
and maintain for the same reasons.
The right time for this kind of minor code tweaking is _after_ all the
code is written and working; maybe even after the first release. _Then_
you go in with a profiler and examine the results, and say "hey, my
program spends 13% of its time in strcmp(), maybe I can improve that by
testing the first char inline before calling the function", or writing
an inline function, or even reversing loops to count down instead of up.
Also, armed with this info you can see whether the changes you make
really help the situation or not... or even make it worse.
On a micro level, I believe the best way is to write the code the most
straightforward way possible first, _then_ when it all works, come back
and see where you can tweak it to be faster. Remember, slower, working
code is always better than faster, broken code.
That being said, if you like to count down and that's your style, that's
great. I have no issue with people cultivating styles that are more
likely to lead to more efficient code! I, myself, quite often use
temporary pointers to walk through arrays rather than incrementing a
counter and using array indexing. I actually do it because I find the
code simpler to understand that way, but it's probably faster, too.
But, I don't think it's a useful exercise for the average programmer to
be examining the assembly output of their current compiler, and trying
to adjust their C coding style accordingly. Programmers should be
worrying about writing straightforward, easy to read, easy to maintain,
portable code first and foremost. Any optimizations on this level can
wait.
--
===============================================================================
Paul D. Smith <[EMAIL PROTECTED]> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
===============================================================================
These are my opinions---Nortel Networks takes no responsibility for them.
------------------------------
From: Eric Wampner <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.networking,comp.os.linux.hardware,linux.dev.net
Subject: Re: Netgear FA310TX
Date: Thu, 26 Aug 1999 11:19:05 -0400
Dave Platt wrote:
> A less expensive workaround for the problem would simply be to recognize
> the symptoms of the chip error and reset the chip, discarding the
> damaged packets (and potentially dropping transmit packets on the
> floor). It would be up to the higher layers in the protocol stack to
> recover from the loss of data. I did something like this a few years
> ago to fix the AMD "lance" driver so that it would recover from
> busmastering errors.
BTW - This works great, I am a Zeos P90 with the AMD53C790 (er 970?)
chip,
I get bus master errors on my console all the time with no apparent
problem
with the network.
If thats the same problem, I think resetting the chip and dumping the
packets works fine for a casual workstation.
eric
--
Eric Wampner Orlando Software Group, Inc. [EMAIL PROTECTED]
Software Engineer (407) 366-0909 [EMAIL PROTECTED]
Systems Administrator fax (407) 366-2721 [EMAIL PROTECTED]
------------------------------
From: Pablo Yaggi <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware
Subject: Multipoint protocol?
Date: Thu, 26 Aug 1999 12:20:04 -0300
This is a multi-part message in MIME format.
==============7B1738E1BF29F30EDF7B9E93
Content-Type: text/plain; charset=us-ascii
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
==============7B1738E1BF29F30EDF7B9E93
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-ID: <[EMAIL PROTECTED]>
Date: Wed, 25 Aug 1999 13:08:22 -0300
From: Pablo Yaggi <[EMAIL PROTECTED]>
X-Mailer: Mozilla 4.01 [en] (Win95; I)
MIME-Version: 1.0
Newsgroups: comp.os.linux.networking
Subject: Multipoint protocol?
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi,
I build a fast serial port board (sync type) for the isa slot.
Now I have the following configuration, 3 PCs with that kind of boards
on
diferent subnets and a concentrator device that makes possible that all
boards transfer to or recive from the others simultaniusly, this
concetrator acts like a hub, but the devices attached to it doesn't have
MAC addresses.
I want to make a whole net with those PCs, so I could write a linux
driver to use
my boards like a 'cua' device, but what protocol do I have to use or
how, to route the subnets to the whole net?. I can't use PPP because is
a point-to-point protocol.
Do I have to write my own interface driver, like 'eth' ones? if so,
please give me some information about how to do it, because I don't have
any :(.
Thank's,
Pablo Yaggi
[EMAIL PROTECTED]
==============7B1738E1BF29F30EDF7B9E93==
------------------------------
** 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
******************************
