Linux-Development-Sys Digest #171, Volume #7 Wed, 8 Sep 99 10:15:21 EDT
Contents:
Re: IDE for c++ dev? (Warren Young)
Re: select() and FD_SETSIZE (Warren Young)
Re: Problems building a cross-compiler (Sasa Ostrouska)
Re: select() and FD_SETSIZE (Warren Young)
Re: Richards Stevens died (Kurt Wall)
Re: Scheduling in Kernel 2.2 (Warren Young)
Re: Linux standards compliance (Warren Young)
Re: Problem porting to LINUX (Warren Young)
Re: glibc-2.1.2 (Andreas Jaeger)
Re: why not C++? (david parsons)
watchdog - multiple instances ("Oliver Lehm")
Re: TAO: the ultimate OS (Donal K. Fellows)
dev->hard_start_xmit ([EMAIL PROTECTED])
Re: spin lock (Josef Moellers)
Re: spin lock (Gerhard Fuernkranz)
XServer (J_Bolz)
Re: acurate timing ("Norm Dresner")
Re: IDE for c++ dev? (Toby Haynes)
----------------------------------------------------------------------------
From: Warren Young <[EMAIL PROTECTED]>
Subject: Re: IDE for c++ dev?
Date: Wed, 08 Sep 1999 02:43:58 -0600
Toby Haynes wrote:
>
> Ian Thompson Bell <[EMAIL PROTECTED]> writes:
>
> > Nix wrote:
> > > After all, there is nothing that emacs cannot do. And that's
> > > official.
> > Apart from be intuitive you mean?
>
> Emacs *is* reasonably intuitive once you discover the following
> routines to tell you about where, what and how.
"Intuitive" means not having to discover things. That's RTFMing, and if
that's the required entry fee, then all editors are intuitive. (I say
this not as a Windows point-and-drool type, but as someone who knows
many editors, including vi and emacs. I'm just injecting a little
reality into the discussion.)
> After that, you realise you can reconfigure anything at all, so if you
> find the interface confusing, you can change it or build your own
> menus.
Oh yes, elisp is intuitive all right. |-<
> 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.
--
= Warren Young: www.cyberport.com/~tangent | Yesterday it worked.
= ICBM Address: 36.8274040N, 108.0204086W, | Today it is not working.
= alt. 1714m | Windows is like that.
------------------------------
From: Warren Young <[EMAIL PROTECTED]>
Subject: Re: select() and FD_SETSIZE
Date: Wed, 08 Sep 1999 02:52:28 -0600
Nix wrote:
>
> [EMAIL PROTECTED] (Alan Curry) writes:
>
> > I'd rather edit
> > /etc/termcap than go through the tic/untic/infocmp compilation cycle.
>
> Users cannot edit /etc/termcap.
No, but they can set their TERMCAP environment variable to the text of a
termcap entry they want to use.
--
= Warren Young: www.cyberport.com/~tangent | Yesterday it worked.
= ICBM Address: 36.8274040N, 108.0204086W, | Today it is not working.
= alt. 1714m | Windows is like that.
------------------------------
From: Sasa Ostrouska <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Problems building a cross-compiler
Date: Wed, 08 Sep 1999 10:14:57 +0200
I tried also in a separate directory like /usr/src/buildegcs and the
result is the same.
I was thinking to try with the glibc-2.1.2 and gcc-2.95.1
Thank you
Sasa
[EMAIL PROTECTED] wrote:
> Don't build in the source directory.
------------------------------
From: Warren Young <[EMAIL PROTECTED]>
Subject: Re: select() and FD_SETSIZE
Date: Wed, 08 Sep 1999 03:10:04 -0600
Kaz Kylheku wrote:
>
> I think we can things up neatly with this table:
>
> Bell Labs intellectuals Berkeley dope-smokers
> -------------------------------------------------------------
> Bourne shell C shell
> poll select
> write talk, talkd
> memcpy and memmove bcopy
> termios sgtty
TLI/XTL sockets
System V IPC (shm*, sem*, msg*) pipe, Unix sockets
14-character filenames 255-char filenames
RATFOR Pascal, Franz Lisp
ed/ex vi
rcs sccs
diddly-squat section 6 games!
ioctl ioctl ;-)
I'm guessing you're not talking about SVR4.x, since that includes a lot
of BSDisms as options to the traditional SysV mechanisms.
Given a choice between SVR3.2 and 4.3BSD, I'd take the dope-smokers.
Between 4.4BSD and SVR4.2, I might still go with the bong mongers, but
it'd be a tougher decision -- I prefer Bourneish shells and /etc/rc?.d
over csh and /etc/rc?. Fortunately, I haven't got to make that choice:
I have Linux. B-)
--
= Warren Young: www.cyberport.com/~tangent | Yesterday it worked.
= ICBM Address: 36.8274040N, 108.0204086W, | Today it is not working.
= alt. 1714m | Windows is like that.
------------------------------
From: Kurt Wall <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.programmer,comp.os.linux.development.apps
Subject: Re: Richards Stevens died
Date: 8 Sep 1999 09:46:04 GMT
In comp.os.linux.development.apps Josh Stern <[EMAIL PROTECTED]> wrote:
>>What tragic news. I feel like we should do something in his memory.
> Someone indicated on /. that Habitat for Humanity is his favorite/designated
> charity (not sure which sense was meant).
The obit mentioned that the family had requested donations to Habitat for
Humanity in lieu of flowers.
Kurt
--
A diplomat is man who always remembers a woman's birthday but never her age.
-- Robert Frost
------------------------------
From: Warren Young <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Scheduling in Kernel 2.2
Date: Wed, 08 Sep 1999 01:47:59 -0600
Christoph Pleger wrote:
>
> What has happened with the scheduling under Kernel 2.2?
You should ask this on this Linux kernel mailing list. There are people
there that can help you: http://www.tux.org/lkml/
--
= Warren Young: www.cyberport.com/~tangent | Yesterday it worked.
= ICBM Address: 36.8274040N, 108.0204086W, | Today it is not working.
= alt. 1714m | Windows is like that.
------------------------------
From: Warren Young <[EMAIL PROTECTED]>
Subject: Re: Linux standards compliance
Date: Wed, 08 Sep 1999 03:34:04 -0600
Peter Samuelson wrote:
>
> What *may* happen, though, is that the UDI backers (i.e. the ones with
> money) get someone to write UDI backend into the kernel and distribute
> *that* as a kernel patch.
This will already happen: Intel committed to porting the reference
implemementation code to Linux months ago. Press release:
http://developer.intel.com/design/servers/dev_guides/content/doc_lib/udig_wp.htm
It occurs to me that it'd be in Linux's best interests to accept these
patches into the kernel if they're of the sort that don't compromise the
rest of the kernel's stability or speed. (Probably also add a config
option to disable UDI.) Then, _don't_ port Linux drivers to UDI, but
just _allow_ UDI drivers to be loaded. Then Linux would be harvesting
UnixWare drivers for free!
> be fulfilled. I don't think that in the end it would help either party
> very much, though.
I don't think the world is going to UDI, but I do think it will give
Linux a real chance at supporting hardware from some of the _very_
recalcitrant vendors like Dialogic who won't release driver programing
info even under NDA. Like lxrun on UnixWare or iBCS on Linux, it's not
the main mechanism for doing work, but it's sure nice to have it around
occasionally.
--
= Warren Young: www.cyberport.com/~tangent | Yesterday it worked.
= ICBM Address: 36.8274040N, 108.0204086W, | Today it is not working.
= alt. 1714m | Windows is like that.
------------------------------
From: Warren Young <[EMAIL PROTECTED]>
Subject: Re: Problem porting to LINUX
Date: Wed, 08 Sep 1999 03:39:26 -0600
"Georg S. Lorrig" wrote:
>
> German version using "cc -c C_TEST.C" I get some _hundred_ error
> messages. It seems that cc doesn't like almost any function declaration
> and the like.
gcc probably hates your K&R function declarations. Welcome to 1999 --
it's time to use ANSI C and prototypes.
--
= Warren Young: www.cyberport.com/~tangent | Yesterday it worked.
= ICBM Address: 36.8274040N, 108.0204086W, | Today it is not working.
= alt. 1714m | Windows is like that.
------------------------------
From: Andreas Jaeger <[EMAIL PROTECTED]>
Subject: Re: glibc-2.1.2
Date: 08 Sep 1999 07:59:28 +0200
>>>>> Paul Kimoto writes:
Paul> In article <[EMAIL PROTECTED]>, Andreas Jaeger wrote:
>> The announcement has been send - as usual - to linux-gcc@vger and
>> libc-alpha. You can check the mail archives (the later via
>> http://sourceware.cygnus.com/glibc).
Paul> It says
Paul> : In case you decide to compile glibc yourself you need to read the file
Paul> : INSTALL. It will explain among other things which tools are
Paul> : necessary. The most important one is the compiler. Although other
Paul> : versions might work it is recommended to get gcc 2.96.
Paul> Should this say "gcc 2.95"? I got no enlightenment from reading INSTALL,
Paul> which seems not to know of anything newer than egcs-1.1.1. (I used the
Paul> glibc patch file to update my source tree.)
It should be gcc 2.95.1 - just another typo in the announcement.
Thanks for reading it;-).
I'm going to fix INSTALL - thanks.
Andreas
--
Andreas Jaeger [EMAIL PROTECTED] [EMAIL PROTECTED]
for pgp-key finger [EMAIL PROTECTED]
------------------------------
From: o r c @ p e l l . p o r t l a n d . o r . u s (david parsons)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Date: 7 Sep 1999 16:47:12 -0700
In article <[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
>My point was that he's added even more pointless and obscure things to C++
>such as reference variables. What the hells the point of those when you
>already have pointers? Also overloading the << and >> to produce a less
>powerfull (for most things) I/O system than *printf and *scanf
I suspect the confusing part was trying to make a syntax UNLIKE
what libc uses, so people wouldn't try to mix and match the two.
It's a real bummer that iostreams (``I'll cut your fingers off
if you use iostreams'' -- me, to employees) were designed after
a session in an apl parlour, and a FILE*-type interface wasn't
chosen instead.
____
david parsons \bi/ FILE foo; foo += W"hello, world\n";
\/
------------------------------
From: "Oliver Lehm" <[EMAIL PROTECTED]>
Subject: watchdog - multiple instances
Date: Wed, 8 Sep 1999 11:53:27 +0200
I need to check that different programs continue running. But by reading the
sources of the watchdog driver I saw that only one open for the driver is
possible.
Is there an extension which allows mutiple instances (maybe a further layer
above the watchdog driver).
------------------------------
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: 8 Sep 1999 11:05:18 GMT
In article <[EMAIL PROTECTED]>,
EdToy <[EMAIL PROTECTED]> wrote:
[...]
> 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.
IOW, dreams are a dime-a-dozen. You can get them free with your
breakfast cereal. Do something about them though, and you wind up
with something far more impressive to the programmer-in-the-street.
If Vladimir takes just one of the topics he lists in his Tao document
and really works at it, he could become a world-expert in relatively
short order. Computer Science is still a young-enough subject for
that to be practical. The results would be worthwhile in themselves,
even without the wider context.
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]
Subject: dev->hard_start_xmit
Date: Wed, 08 Sep 1999 11:40:41 GMT
hi all,
i am trying to make a kernel network module. ive added to syscalls to
send and recieve. however when i try to send using dev->hard_start_xmit
the function returns 0 but the packet is not recieved by the
destination. i used dev->hard_header to make the ethernet headers. then
locked the skb and sent it to hard_start_xmit. my recieve function
recieves can recieve ip packets but does not recieve my packets. What am
i doing wrong ?
thanx in advance.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Josef Moellers <[EMAIL PROTECTED]>
Subject: Re: spin lock
Date: Wed, 08 Sep 1999 12:40:48 +0200
Gerhard Fuernkranz wrote:
> =
> Tristan Wibberley wrote:
> =
> > > Is there any documentaton about how to use those spinlock
> > > kernel functions?
> >
> > less /usr/src/linux/Documentations/spinlocks.txt
> =
> I'm wondering which parts of the kernel have to be
> protected by spinlocks and which parts don't have to.
> =
> There is also some SMP documentation in the same directory
> which mentions, that the kernel acquires a global lock at
> all entry points.
> =
> So I'm wondering which kernel parts are already protected
> by the global lock and which have to protect themselves
> by using spinlocks?
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
be consistent) or perhaps even across a bus-cycle boundary have to use
the same locking mechanism in order to obtain correct results in the
case of an update by another instance.
Using a global lock is simple and protects against deadlocks, but leaves
much to be desired wrt concurrency. Breaking down locking to lower
levels and a finer granularity increases concurrency (e.g. two instances
can modify different resources at the same time), but is more difficult
to get it right. Deadlock prevention is difficult and might require lock
levels which again require additional overhead obtaining a lock (you
want the locking code to be as fast as possible when the lock is free)
and requires much thought about the proper lock-level to use. Besides:
what do you do when a lock is requested which has an incorrect lock
level? Add to this the problem that locks might need to be acquired
during interrupt handling and you start to see the complexity of the
issue.
<COMMERCIAL>
Our OS (SINIX) is fully parallelized and I can assure you that it has
costs a lot of headache to write a driver which is fully paralellized,
too.
</COMMERCIAL>
One could write books about this issue.
Josef
-- =
PS Die hier dargestellte Meinung ist die persoenliche Meinung des
Autors!
PS This article reflects the author=B4s personal views only!
------------------------------
From: Gerhard Fuernkranz <[EMAIL PROTECTED]>
Subject: Re: spin lock
Date: Wed, 08 Sep 1999 12:36:40 +0200
Tristan Wibberley wrote:
> > Is there any documentaton about how to use those spinlock
> > kernel functions?
>
> less /usr/src/linux/Documentations/spinlocks.txt
I'm wondering which parts of the kernel have to be
protected by spinlocks and which parts don't have to.
There is also some SMP documentation in the same directory
which mentions, that the kernel acquires a global lock at
all entry points.
So I'm wondering which kernel parts are already protected
by the global lock and which have to protect themselves
by using spinlocks?
Gerhard
------------------------------
From: J_Bolz <[EMAIL PROTECTED]>
Subject: XServer
Date: 8 Sep 1999 12:26:57 GMT
Hi @ll!
I have a question, that sounds simple but it isn't:
How does a XServer work?
e.g. Which program sends the data to the server?
Or how does the server get his data and where does he put them?
If I send a command to the server (e. g. draw a blue circle) what
is the server doing?
Does he simple draw the circle in blue or have I to say: "put a
dot on xy in color
BLUE)?
I'll be happy a lot for answers!
THX
JBO
P.S. sorry for my english ;-)
My E-Mail: [EMAIL PROTECTED]
------------------------------
From: "Norm Dresner" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux,comp.os.linux.misc
Subject: Re: acurate timing
Date: 8 Sep 1999 12:47:25 GMT
Virginie Galtier <[EMAIL PROTECTED]> wrote in article
<[EMAIL PROTECTED]>...
> Hi
>
> 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)?
>
> Virginie
The obvious answer is "Of course," but therein lies a tale (or three).
Ignore hardware, for a moment, you still have recourse to statistics: If
you average the results of N trials, you improve your resolution by
sqrt(N). Thus, if you average 100 time-trials, the average has .1*jiffies
accuracy.
Also, if the duration of the process you're trying to time is less than (or
even on the same order of magnitude as) a jiffy, you could always run
several instances of the process in a loop and divide by the loop count
(you did remember to subtract the loop overhead, didn't you?).
I've used variations on these techniques for years to derive timing for
C/assambly functions that are accurate to .1 uSeconds. Of course, you need
patience to let the process run for, perhaps, tens of thousands of trials,
but then you're only doing this once, right?
Now for the hardware answers. In out-of-the-box linux, the answer is -- in
a word -- NO. But since you have an open source system, there's no reason
why you can't change the value of a jiffy and thereby increase your
resolution. If you're interested in traveling this route, look at
/usr/include/asm/param.h where the value of HZ is defined.
Norm
------------------------------
From: Toby Haynes <[EMAIL PROTECTED]>
Subject: Re: IDE for c++ dev?
Date: 08 Sep 1999 08:53:38 -0400
Warren Young <[EMAIL PROTECTED]> writes:
> Toby Haynes wrote:
> > Ian Thompson Bell <[EMAIL PROTECTED]> writes:
> > > Nix wrote:
> > > > After all, there is nothing that emacs cannot do. And that's
> > > > official.
> > > Apart from be intuitive you mean?
> > Emacs *is* reasonably intuitive once you discover the following
> > routines to tell you about where, what and how.
> "Intuitive" means not having to discover things. That's RTFMing, and if
> that's the required entry fee, then all editors are intuitive. (I say
> this not as a Windows point-and-drool type, but as someone who knows
> many editors, including vi and emacs. I'm just injecting a little
> reality into the discussion.)
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
what the command is called, or where it is keymapped. There are very
few times when using Emacs that I fail to find a new function that I'm
after on the first or second try.
> > After that, you realise you can reconfigure anything at all, so if you
> > find the interface confusing, you can change it or build your own
> > menus.
> Oh yes, elisp is intuitive all right. |-<
Emacs lisp is logical - it requires a different approach to, say, C
programming, but there really isn't anything really nasty hidden in
there. That's not to say that things can't get convoluted, but you can
do that in any language (Perl being my personal favourite on that
score :-) ).
> > 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.
Ummm. I hate to tell you this, but I have this little menu called Help
on the far right of my menubar complete with 'Customise ->' which
covers almost all aspects of customising Emacs in a point-and-click
fashion, and 'Options ->' which allows you to toggle on and off most
of the everyday options, like syntax highlighting, paragraph
filling. Oh, and before you jump up and down and point out that Xemacs
has a slightly different menu structure, that is because Xemacs is a
different code tree (although a fair number of the Emacs lisp packages
run on both Emacs and Xemacs).
Emacs tends to scare people off early for some reason, possibly
because there are so many commands which are out there to be played
with. The initial learning curve is not as steep as you might imagine,
because most Emacs distributions come ready-to-use out of the box. I
don't deny that I get more out of Emacs now than I did 5 years ago
when I started learning it, but then again, knowledge is power!
Cheers,
Toby
--
Toby Haynes
The views and opinions expressed in this message are my own, and do
not necessarily reflect those of IBM Canada.
------------------------------
** 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
******************************
