Linux-Development-Sys Digest #756, Volume #7 Mon, 10 Apr 00 22:13:20 EDT
Contents:
Re: about share memory and semaphore (bill davidsen)
Re: To core or not to core - Part 2 (Michael Wojcik)
Development (Ivan Van den Bossche)
Re: Development (Kaz Kylheku)
Re: To core or not to core - You tell me (Mark McIntyre)
syscall during shrinking? (Weiguang Shi)
4th Annual Linux Showcase & Conference - Call for Papers, Final Notice (Moun Chau)
Re: syscall during shrinking? (Mark Wooding)
Re: To core or not to core - Part 2 (Logan Shaw)
Re: Absolute failure of Linux dead ahead? (Tom Mitchell)
A driver for Read/Writeable cdrom (TEAC CD-W54E) ? (Darius Samani)
Re: To core or not to core - You tell me ("Mike Spooner")
Re: To core or not to core - You tell me ("-hs-")
Re: Development (Dave Nejdl)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Subject: Re: about share memory and semaphore
Date: 10 Apr 2000 20:38:05 GMT
In article <[EMAIL PROTECTED]>, Eddy <[EMAIL PROTECTED]> wrote:
| I am using RH6.1 . Is it possible to config the share memory parameter and
| semaphore parameter without recompiling kernel ?
I'm not sure what you mean to configure, does the standard kernel not
include IPC? Type 'ipcs' and see if it complains.
Sorry, I have 5.2 systems, but my 6.1 systems are all running a kernel
I built myself, so I can't test. The 5.1 (2.0.36) systems run ipcs and
should have IPC.
If you mean 'enable' it should be there, if you want to diddle the
limits, /proc/sys/kernel/shmmax is there.
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
"Doing interesting things with little computers since 1979"(tm)
The hardest test of maturity is knowing the difference between
resisting temptation and missing a once-in-a-lifetime opportunity.
------------------------------
From: [EMAIL PROTECTED] (Michael Wojcik)
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.unix.questions,comp.unix.programmer
Subject: Re: To core or not to core - Part 2
Date: 10 Apr 2000 19:49:24 GMT
Reply-To: [EMAIL PROTECTED]
[This thread is *much* too widely crossposted. I'm restricting followups
to comp.unix.programmer, as the least off-topic group in the original
list.]
In article <[EMAIL PROTECTED]>, Chuck Dillon <[EMAIL PROTECTED]> writes:
> Mark Langsdorf wrote:
> > In development code, I'd go for the redundancy, just for the safety
> > it provides. Then strip out all the redundancy in production.
> Thanks for the clarification. But I think it's important we be clear
> here since the range of experience of readers is vast in the group.
>
> I have a problem with your use of 'safety' here. It implies to me
> that the called function should be more tolerant of such errors
> passed from above during development.
I don't see anything in Mark's posts to imply that. His "redundancy"
appears to refer to additional assertions, not tolerance in lower-
level functions for invalid input. (Unless you consider flagging an
error being tolerant.)
> IMHO it should be the opposite. The called function should be
> as deterministically and repeatable non-tolerant as reasonable
> so as to shine a bright light on any errors passed from above.
In my experience, there's nothing like explicitly validating the
domain of the input parameters to "deterministically and repeatabl[y]"
illuminate such errors.
> This is generally done with asserts (man assert) that are
> conditionally compiled into the code and so can be 'stripped'
> simply by removing/changing a symbol.
I disagree completely with the practice of blindly removing parameter
checking from production code. Cycles are relatively cheap in most
applications, and often there's no detectable performance hit from
leaving parameter-checking in. (If your function parameter-checking
is in an inner loop, why are you calling a function and incurring
*that* overhead there in the first place?)
But I don't consider the assert() macro a particularly good way to
vet parameters anyway. It's a lazy catch-all. Each function should
decide how best to respond to invalid input - which may come in
several classes that demand different handling - and that response
should generally be in-band, in the form of an error code returned
to the caller, not something that completely alters the control flow,
like a signal. assert() is fine for quick & dirty coding, but I
wouldn't want to see it used in production code - even while that
code's in development.
And others have already noted some of the hazards of automatically
removing vetting by changing the build type, such as assertions with
side effects. Yes, assertions shouldn't have side effects, but
sometimes coders make mistakes.
--
Michael Wojcik [EMAIL PROTECTED]
AAI Development, MERANT (block capitals are a company mandate)
Department of English, Miami University
How can I sing with love in my bosom?
Unclean, immature and unseasonable salmon. -- Basil Bunting
------------------------------
From: Ivan Van den Bossche <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Development
Date: Mon, 10 Apr 2000 20:53:04 GMT
Hello everybody,
What do I need to know to start helping in the development of the Linux
kernel?
Where can I find that information on the web?
I have some knowledge of C.
Thanks
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Development
Reply-To: [EMAIL PROTECTED]
Date: Mon, 10 Apr 2000 21:07:35 GMT
On Mon, 10 Apr 2000 20:53:04 GMT, Ivan Van den Bossche
<[EMAIL PROTECTED]> wrote:
>Hello everybody,
>
>What do I need to know to start helping in the development of the Linux
>kernel?
>Where can I find that information on the web?
You join the kernel development mailing list, and have a look at its list
of things that need to be done. Then pick one.
>I have some knowledge of C.
You don't have to have perfect knowledge of C, but it helps to have solid
software engineering skills which usually go hand in hand with mastery of some
systems programming language.
For working on a kernel, you need to understand concurrent programming and have
cast iron debugging skills; often you have to find a software defect given
minimal information from a crash.
Your program logic has to cover every failure possibility and so something
meaningful; your code can't just give up and call exit() at every run-time
difficulty, like so many application-level C programs do.
------------------------------
From: Mark McIntyre <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.lang.c++,comp.unix.programmer
Subject: Re: To core or not to core - You tell me
Date: Mon, 10 Apr 2000 23:28:46 +0100
Reply-To: [EMAIL PROTECTED]
On Wed, 05 Apr 2000 10:07:09 -0400, Ron Natalie <[EMAIL PROTECTED]>
wrote:
>
>
>Joe Pfeiffer wrote:
>>
>> David Williams <[EMAIL PROTECTED]> writes:
>> >
>> > a) 0 == NULL (an integral constant expression with value 0...
>> > converted by comparsion...this produces a null pointer..)
>> > ^^^^^^^^^^^^^^^^^^^^^^^
>> > ??? are they the same or not?? NB A conversion could be taking
>> > place implying that they are not.
>>
>> This is a subtle point, and you've picked up on it perfectly. It is
>> possible, in principle, for the conversion to take place so that
>> (void *) 0 is not a word full of all zeroes, and NULL need not be
>> represented as all zeroes.
>
>NULL is necessarily an integer zero constant.
n2874
7.17
NULL
which expands to an implementation-defined null pointer
constant
6.3.2.1
[#3] An integer constant expression with the value 0, or
such an expression cast to type void *, is called a null
pointer constant.
thus NULL may be either an integer or a void*. Its incorrect to state
that it _must_ be an integer.
Mark McIntyre
C- FAQ: http://www.eskimo.com/~scs/C-faq/top.html
------------------------------
From: Weiguang Shi <[EMAIL PROTECTED]>
Subject: syscall during shrinking?
Date: Mon, 10 Apr 2000 16:34:41 -0600
Hi, there:
Could you please tell me what system calls should the action of shrink
a file's size invoke (e.g., as I "ed" a file and delete several lines and
type a "w")?
Thanks very much.
Weiguang
------------------------------
Crossposted-To:
alt.os.linux,comp.os.linux,comp.os.linux.admin,comp.os.linux.advocacy,comp.os.linux.development,comp.os.linux.development.apps
From: [EMAIL PROTECTED] (Moun Chau)
Subject: 4th Annual Linux Showcase & Conference - Call for Papers, Final Notice
Date: Mon, 10 Apr 2000 22:48:05 GMT
4th Annual Linux Showcase and Conference, Atlanta
October 10 - 14, 2000
Cobb Galleria
Atlanta, Georgia, USA
http://www.linuxshowcase.org
Sponsored by USENIX, the Advanced Computing Systems Association, and the
Atlanta Linux Showcase, in cooperation with Linux International
LINUX ENTHUSIASTS AND PROFESSIONALS: The highlight of this year's Linux
community calendar is undoubtably the Annual Linux Showcase and
Conference. Now in its fourth year, ALS is specifically designed for
the Linux enthusiast, with an emphasis on high-caliber technical
knowledge. This conference is developed by a volunteer community of
computing professionals and by USENIX, a not-for-profit technical
association respected for its tradition of in-depth technical
conferences.
ALS 2000 promises to be the biggest event in ALS history, expanding its
technical program to include more tutorials, refereed papers, invited
talks, Birds-of-a-Feather sessions, hothouses, and opportunities for
informal discussions with Linux experts, professionals, and vendors. The
conference includes a three-day vendor exhibition in which more than 80
companies will showcase their latest products and services.
We are currently seeking submissions for Technical White Papers,
Works-In-Progress Reports, Talks/Panel Session proposals, and Tutorial
presentation proposals for this event. Suggested topics include
discussions on the development of Linux and Open Source platforms,
applications and tools as well as the implementation, maintenance and
growth of Linux systems in small and large environments. Detailed topic
suggestions and submission guidelines can be found on our website:
http://www.linuxshowcase.org.
===============================================================
IMPORTANT DATES
Submissions due:
Extreme Linux Workshop: April 17, 2000
Hack Linux/Use Linux Tracks: May 1, 2000
Notification to authors:
Extreme Linux Workshop: June 16, 2000
Hack Linux/Use Linux Tracks: June 30, 2000
Registration material available: July 2000
Editorial revisions due (Extreme Linux Workshop): July 23, 2000
Final papers due (for all tracks/workshops): August 24, 2000
===============================================================
Join us in the premier technical conference for Linux enthusiasts and
professionals! This conference is sponsored by USENIX, the Advanced
Computing Systems Association, and the Atlanta Linux Showcase, in
cooperation with Linux International.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: syscall during shrinking?
Date: 10 Apr 2000 23:04:07 GMT
Weiguang Shi <[EMAIL PROTECTED]> wrote:
> Could you please tell me what system calls should the action of shrink
> a file's size invoke (e.g., as I "ed" a file and delete several lines and
> type a "w")?
To answer the question as asked, `ed' will:
* open(file, O_RDONLY)
* read() the file until EOF (read returns zero).
* close()
Then you edit, and save the file. `ed' will then:
* open(file, O_WRONLY | O_CREAT | O_TRUNC, 0666)
* write() all of the file's contents
* close()
That's probably not what you wanted to hear. I suspect that you really
wanted to know about the ftruncate(2) function, which you should look up
in a convenient manual page.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Logan Shaw)
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.unix.questions,comp.unix.programmer
Subject: Re: To core or not to core - Part 2
Date: 10 Apr 2000 18:58:00 -0500
In article <[EMAIL PROTECTED]>, Chuck Dillon <[EMAIL PROTECTED]> wrote:
>Mark Langsdorf wrote:
>> In development code, I'd go for the redundancy, just for the safety
>> it provides. Then strip out all the redundancy in production.
>
>Thanks for the clarification. But I think it's important we be clear
>here since the range of experience of readers is vast in the group.
>
>I have a problem with your use of 'safety' here. It implies to me
>that the called function should be more tolerant of such errors
>passed from above during development.
>
>IMHO it should be the opposite. The called function should be
>as deterministically and repeatable non-tolerant as reasonable
>so as to shine a bright light on any errors passed from above.
Probably, both approaches are good for development.
At the beginning, functions that check for things like null pointers
can be handy so that a minor bug doesn't prevent you from having a
semi-working, non-crashing version of the software you're using. Yes,
all bugs are important and need to not be ignored, but sometimes other
bugs are more important and you need to be able to get other
development done without the requirement that you fix all the null
pointer bugs first.
Then, once the thing is more stable, you might make your functions very
intolerant so that you expose bugs and can fix them.
And then, for release, make them fast, since you should have fixed the
bugs by then.
- Logan "thesis, antithesis, and synthesis" Shaw
------------------------------
From: Tom Mitchell <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Absolute failure of Linux dead ahead?
Date: Mon, 10 Apr 2000 16:59:54 -0700
Reply-To: [EMAIL PROTECTED]
On Thu, 23 Mar 2000, Christopher Browne wrote:
> >What's wrong with Modula-3? ;)
>
> Nothing in particular.
>
> Of course, it wouldn't make sense to *merely* rewrite it in Modula-3;
> it would make *more* sense to do some redesign to take advantage of
> the functionality Modula-3 offers.
>
> It's an interesting idea; some of the people that waste time
> blathering about redoing Linux in C++ should take a look at the M3
Are there M3 compilers in the gnu world that are up to the task?
At least three processor targets.
------------------------------
From: Darius Samani <[EMAIL PROTECTED]>
Subject: A driver for Read/Writeable cdrom (TEAC CD-W54E) ?
Date: Mon, 10 Apr 2000 17:20:58 -0700
Would anyone know if there are any drivers for
Teac Read/Writeable cdrom (model CD-W54E) ? If so,
could you point me to where they're located ?
Many Thanks,
Darius
------------------------------
From: "Mike Spooner" <[EMAIL PROTECTED]>
Subject: Re: To core or not to core - You tell me
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.lang.c++,comp.unix.programmer
Date: Tue, 11 Apr 2000 00:30:02 GMT
Mark McIntyre <[EMAIL PROTECTED]> wrote in article
<[EMAIL PROTECTED]>...
> On Wed, 05 Apr 2000 10:07:09 -0400, Ron Natalie <[EMAIL PROTECTED]>
> wrote:
>
> >
> >
> >Joe Pfeiffer wrote:
> >>
> >> David Williams <[EMAIL PROTECTED]> writes:
> >> >
> >> > a) 0 == NULL (an integral constant expression with value 0...
> >> > converted by comparsion...this produces a null pointer..)
> >> > ^^^^^^^^^^^^^^^^^^^^^^^
> >> > ??? are they the same or not?? NB A conversion could be
taking
> >> > place implying that they are not.
> >>
> >> This is a subtle point, and you've picked up on it perfectly. It
is
> >> possible, in principle, for the conversion to take place so that
> >> (void *) 0 is not a word full of all zeroes, and NULL need not be
> >> represented as all zeroes.
> >
> >NULL is necessarily an integer zero constant.
>
> n2874
> 7.17
> NULL
> which expands to an implementation-defined null pointer
> constant
> 6.3.2.1
> [#3] An integer constant expression with the value 0, or
> such an expression cast to type void *, is called a null
> pointer constant.
>
> thus NULL may be either an integer or a void*. Its incorrect to state
> that it _must_ be an integer.
>
It is also not comletely correct to say that it must be zero. The ANSI
C standard
allows NULL to be an arbitrary bit-pattern, but insists that the
compiler convert
it to a zero value when assigning or comparing it with an integer type.
One C compiler (for a CPU with signed addresses!) used a value of
all-1s
for NULL (all-0s was in the middle of the address-space). For things
like:
int i, x;
if ((i == NULL) || (x == 0))
everything is fine, but when attempting to "clear" allocated structures
that
have pointer members, you have to initialise the pointer members with
an explicit assignment...
First, the wrong (non-portable) way:
struct {int count; char *ptr} s;
memset(s, 0, sizeof(s));
Now the portable way:
struct {int count; char *ptr} s;
memset(s, 0, sizeof(s));
s->ptr = NULL;
The difference is that the compiler cannot tell that the memset() call
is effectively being used to assign to each member of the structure:
ANSI C only guarantees the automatic (invisible) conversion between
internal and external representations of NULL for *explicit*
assignments
and comparisons.
------------------------------
From: "-hs-" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.lang.c++,comp.unix.programmer
Subject: Re: To core or not to core - You tell me
Date: Tue, 11 Apr 2000 03:08:40 +0200
Mike Spooner a �crit dans le message <01bfa34c$f267e3c0$0b00a8c0@mert>...
>Now the portable way:
>
> struct {int count; char *ptr} s;
>
> memset(s, 0, sizeof(s));
> s->ptr = NULL;
Fine, but what about:
struct {int count; char *ptr} s ={0};
In this case, the compiler will write the correct initialisation code for
you.
--
-hs- "Stove"
CLC-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
ISO-C Library: http://www.dinkum.com/htm_cl
"Really? When run on my machine, a printed copy of the C FAQ leaps
from the monitor and whacks me over the head.." -- Chris Mears CLC
------------------------------
From: Dave Nejdl <[EMAIL PROTECTED]>
Subject: Re: Development
Date: Tue, 11 Apr 2000 01:30:32 GMT
Kaz Kylheku wrote:
> On Mon, 10 Apr 2000 20:53:04 GMT, Ivan Van den Bossche
> <[EMAIL PROTECTED]> wrote:
> >Hello everybody,
> >
> >What do I need to know to start helping in the development of the Linux
> >kernel?
> >Where can I find that information on the web?
>
> You join the kernel development mailing list, and have a look at its list
> of things that need to be done. Then pick one.
>
> >I have some knowledge of C.
>
> You don't have to have perfect knowledge of C, but it helps to have solid
> software engineering skills which usually go hand in hand with mastery of some
> systems programming language.
>
> For working on a kernel, you need to understand concurrent programming and have
> cast iron debugging skills; often you have to find a software defect given
> minimal information from a crash.
>
> Your program logic has to cover every failure possibility and so something
> meaningful; your code can't just give up and call exit() at every run-time
> difficulty, like so many application-level C programs do.
I've been looking for resources on how to do kernel level debbuging. Any
suggestions?
------------------------------
** 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
******************************
