Linux-Development-Sys Digest #897, Volume #6 Sun, 27 Jun 99 14:14:06 EDT
Contents:
Re: Trouble patching kernel 2.2.10 (Martin Wilhelm)
Re: Why not C++ (Bruce Hoult)
Re: Why we are still holding on to X Windows (Tristan Wibberley)
Compilation errors with 2.2.10 ([EMAIL PROTECTED])
Re: Can't export '/' (Aaron Thompson)
Re: Why not C++ (NF Stevens)
Re: TAO: the ultimate OS (Christopher B. Browne)
Re: using C++ for linux device drivers (Don Waugaman)
Re: Trouble patching kernel 2.2.10 (Don Waugaman)
Re: File Allocation Tables (Adam Brinley Codd)
Re: Why we are still holding on to X Windows (Mario Klebsch)
Re: Why not C++ (John E. Davis)
Re: Why not C++ (John E. Davis)
Re: Compilation errors with 2.2.10 (Marc Mutz)
Re: TAO: the ultimate OS (Robert Forsyth)
Re: Why we are still holding on to X Windows (Chris Hedley)
Re: Trouble patching kernel 2.2.10 (Marc Mutz)
Re: Can't export '/' ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Martin Wilhelm <[EMAIL PROTECTED]>
Subject: Re: Trouble patching kernel 2.2.10
Date: Sun, 27 Jun 1999 12:58:58 +0200
Reply-To: [EMAIL PROTECTED]
user wrote:
>
> Did anyone else have trouble applying the kernel patch 2.2.10?
>
> I started with 2.2.5 and appled 2.2.6, 2.2.7, 2.2.8, 2.2.9.
>
> Patch 2.2.10 failed.
>
> Specifically, two patches contain the following line:
> \ No newline at end of file
Edit the patch with an editor and remove the line
"\ No newline at end of file".
Martin
--
martin wilhelm \ thueringen netz e.V. \ cube e.V. (iG)
[EMAIL PROTECTED] \ [EMAIL PROTECTED] \ [EMAIL PROTECTED]
ICQ: 2316518 (selten) \ [EMAIL PROTECTED] \ [EMAIL PROTECTED]
FAX: 089 6661 760496 \ www.thur.de \ www.cube-ev.org
------------------------------
From: [EMAIL PROTECTED] (Bruce Hoult)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: Mon, 28 Jun 1999 00:32:47 +1200
In article <[EMAIL PROTECTED]>, Chris Double <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Bruce Hoult) writes:
>
> > > In practice, C++ is a much more complex language. As such, C++
> > > compilers are much more complex beasts. And that is why some C++
> > > compilers do not generate as good code as the equivalent C compilers do.
> >
> > I'd love to see examples.
> [...snip...]
> >
> > I'm afraid I basically don't use any other compilers. Which C++ compilers
> > are bad?
>
> In a recent Windows Developer Journal (June 1999) they printed an
> article on a Microsoft Visual C++ 6.0 bug. Some code in C++ mode
> caused incorrect assembler to be generated resulting in an infinite
> loop. The exact same code in C mode compiled and executed as expected.
>
> Chris.
Heh. I could make a really cheap shot there... ;-)
Bad C++ compiler noted, thanks.
-- Bruce
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why we are still holding on to X Windows
Date: Sat, 26 Jun 1999 13:21:08 +0100
Reply-To: [EMAIL PROTECTED]
Justin Vallon wrote:
>
> mlw <[EMAIL PROTECTED]> writes:
>
> > > That was the extent of the capability of sound at the
> > > time. We now have far better sound capabilities, so X should continue its
> > > sound support and be extended for these new capabilities.
> >
> > No, a network streaming audio format/protocol should be a separate
> > standard.
>
> I'm not sure that the distinction is that clear. In 99.99% of the
> cases, an applications sound I/O and graphics I/O go to the same
> place: the user. It seems superfluous to create an alternate
> protocol.
They do go to the same place, but you wouldn't want to travel from on
place to another in a plane if it was going to be limited by travelling
on roads, and you wouldn't want to send sound from one place to another
if it was going to be limited by the X protocol.
> While the X protocol should most likely not include sound support, it
> should provide a mechanism for piggybacking other protocols on top of
> the X stream. A hypothetical 'XAudioClient' library could use the same X
> display pipe, with an 'XAudioServer' server extension playing the sound.
Get *good* QoS support out of the X protocol and it might get done.
Otherwise, whether it's in the same process or not, and whether it's on
the same socket or not, even whether it uses the same protocol or not,
is *very* inconsequential - thus separation becomes a signifacant factor
in the design, with no speed/simplicity reasons to put it into the X
protocol (in fact, with speed/simlicity reasons to keep it out).
The X protocol had a couple of things, which neatness would command not
to put them in. They are there because computers used to be slower. It
would be silly to include things in there when good design should keep
them out, and computers are now powerful enough to have an extra socket
open, and (in some implementations) an extra server process.
If you wanted, you could write a client library that was as simlilar in
concept to Xlib as possible but to still be useful for sound - but keep
sound out of X itself.
--
Tristan Wibberley Linux is a registered trademark
of Linus Torvalds.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.misc
Subject: Compilation errors with 2.2.10
Date: Sun, 27 Jun 1999 12:33:09 GMT
Hi
I'm wasn't sure which was the appropriate group to post for this problem
so I chose a selection, sorry if its in the wrong one. (Also appologies
if this problem has been raised before).
I've tried to compile kernel 2.2.10 on a base slackware 3.6 system (2.0.35
and gcc 2.7.2.3) but I get the following compilation error:
:
:
make all_targets
make[2]: Entering directory `/usr/src/linux-2.2.10/arch/i386/lib'
gcc -D__KERNEL__ -I/usr/src/linux-2.2.10/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -pipe -fno-strength-reduce -m486 -malign-loops=2 -malign-jumps=2
-malign-functions=2 -DCPU=686 -c -o checksum.o checksum.c
checksum.c:200: redefinition of `csum_partial_copy'
checksum.c:105: `csum_partial_copy' previously defined here
{standard input}: Assembler messages:
{standard input}:185: Fatal error: Symbol csum_partial_copy already defined.
make[2]: *** [checksum.o] Error 1
make[2]: Leaving directory `/usr/src/linux-2.2.10/arch/i386/lib'
make[1]: *** [first_rule] Error 2
make[1]: Leaving directory `/usr/src/linux-2.2.10/arch/i386/lib'
make: *** [_dir_arch/i386/lib] Error 2
This to me looks like a compiler bug as the function on line 105 is
csum_partial_copy_fromuser() but on 200 its csum_partial_copy().
Has anyone else come across this problem and is there a way around it (short
of the nightmare process of downloading and installing a new compiler)?
Thanks for any help
NJR
.
------------------------------
From: Aaron Thompson <[EMAIL PROTECTED]>
Subject: Re: Can't export '/'
Date: Sun, 27 Jun 1999 15:28:52 GMT
David Rees wrote:
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > >>>>> "David" == David Yeung <[EMAIL PROTECTED]> writes:
> >
> > Not security. But do you have other entries? knfsd is more picky
> > than the old user-mode nfsd. It won't let you export both a directory
> > and a subdirectory of that.
> >
>
> I've been wondering about the same thing. Is there a workaround to
> this? It's really a PITA. If I want to export only some sub directory
> to a client, but the whole filesystem to another, I can't do it!
>
> -Dave
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
What happens if you make a symlink to the subdirectory and export the
symlink?
------------------------------
From: [EMAIL PROTECTED] (NF Stevens)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: Sun, 27 Jun 1999 17:31:14 GMT
[EMAIL PROTECTED] (Nathan Myers) wrote:
>NF Stevens <[EMAIL PROTECTED]> wrote:
>>[EMAIL PROTECTED] (Nathan Myers) wrote:
>>
>>>If you don't know C++ templates, you don't know C++ at all. It is
>>>templates, for example, that make it possible to write a C++ library
>>>that does matrix operations as efficiently as specially-optimizing
>>>Fortran on machines specifically designed to run Fortran well. Unlike
>>>Fortran, though, C++ templates are not tuned specificially for matrix
>>>math, so can be used to accomplish similar wonders in any area.
>>
>>I have to disagree with this. Templates do not in any way improve
>>the efficiency of generated code. They are no faster (and no
>>slower) than the equivalent hand written code. Templates only
>>improve the efficiency of the programmer since only one (templated)
>>version has to be coded rather than individual versions for each
>>template class.
>
>C++ cannot of course be faster than the equivalent assembly
>code, but the C++ compiler can optimize code better than you
>can by hand in C, because it knows more about expressions than
>you can tell the C compiler.
That was not the point. I was comparing the code generated
by instanciation of a template with hand written C++ code.
The fact that templates expand to C++ code means that
_templates_ cannot improve the efficiency of code.
Norman
------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Subject: Re: TAO: the ultimate OS
Reply-To: [EMAIL PROTECTED]
Date: Sat, 26 Jun 1999 21:32:19 GMT
On 26 Jun 1999 18:46:57 GMT, Paul Jackson <[EMAIL PROTECTED]> posted:
>As someone who lives in ...
>
> that "niche" of people that prefer to spend their
> nights redesigning the allocation of disk space
> between Linux and WinTel.
>
>I can confirm what cbbrowne recommended: Partition Magic suits
>me fine for resizing my NT/Win/Linux/DOS/Warp/... partitions.
And here it is worth mentioning that the issue is *not* that there
would be no value in there being a "free" alternative to Partition
Magic; it is that there is not enough value (e.g. - the "niche" is
small enough) to put it high on the "must-do" list.
--
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer <http://www.hex.net/~cbbrowne/lsf.html>
[EMAIL PROTECTED] - "What have you contributed to free software today?..."
------------------------------
From: [EMAIL PROTECTED] (Don Waugaman)
Subject: Re: using C++ for linux device drivers
Date: 27 Jun 1999 09:30:41 -0700
In article <[EMAIL PROTECTED]>,
Justin Vallon <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Nathan Myers) writes:
>
>> Justin Vallon <[EMAIL PROTECTED]> wrote:
>> >void *::operator new(size_t s) { return kmalloc(s, GFP_KERNEL); }
>> >void ::operator delete(void *p) { kfree(p); }
>> >
>> >I think we are agreeing here. No?
>>
>> No. This neglects error recovery. Also, the declaration of pointer
>> types above is not C++-like. In good C++ we use "void* p", not "void *p".
>
>If kmalloc fails, 0 is returned (or it should be). If ::operator new
>fails to allocate memory, it is free to return 0.
Not true any more. ::operator new (or X::operator new, for any class X)
must either return a pointer to an area of storage of sufficient size and
alignment for the type, or end up throwing an std::bad_alloc exception.
(The exception is usually thrown by the current new_handler for the default
::operator new function.)
The new (nothrow) syntax (used like this: X* = new (nothrow) X;) will do
what you are thinking of - return a valid pointer or 0.
> In that case, C++
>will not construct an object, and new T() will return 0. The caller
>must check that new returns a non-zero pointer.
Only if you use new (nothrow) - which would most likely be the only type
of new used in a kernel, assuming that one would not prefer to use the
placement form of new to create objects, as I believe that the kernel
allocates memory in pages.
--
- Don Waugaman ([EMAIL PROTECTED]) O- _|_ Will pun
Web Page: http://www.cs.arizona.edu/people/dpw/ | for food
In the Sonoran Desert, where we say: "It's a dry heat..." | <><
While you're at it, why don't you give me a nice paper cut and pour
lemon juice on it? - Miracle Max
------------------------------
From: [EMAIL PROTECTED] (Don Waugaman)
Subject: Re: Trouble patching kernel 2.2.10
Date: 27 Jun 1999 09:33:26 -0700
In article <[EMAIL PROTECTED]>, user <[EMAIL PROTECTED]> wrote:
>Did anyone else have trouble applying the kernel patch 2.2.10?
I did, initially - same problem.
>I started with 2.2.5 and appled 2.2.6, 2.2.7, 2.2.8, 2.2.9.
>Patch 2.2.10 failed.
>Specifically, two patches contain the following line:
> \ No newline at end of file
[ snip ]
>My version of patch is 2.1b.
>To fix the problem I just deleted the two lines (1764 and 17450) and patch worked
>fine.
That works. Upgrading to patch 2.5 also works, and can cause you less
down the road with the next set of patches...
--
- Don Waugaman ([EMAIL PROTECTED]) O- _|_ Will pun
Web Page: http://www.cs.arizona.edu/people/dpw/ | for food
In the Sonoran Desert, where we say: "It's a dry heat..." | <><
Three out of every four people make up 75 percent of the population.
------------------------------
Date: Sun, 27 Jun 1999 11:37:49 +0100
From: Adam Brinley Codd <[EMAIL PROTECTED]>
Subject: Re: File Allocation Tables
> You'll find some format info in the Documentation directory of the
> kernel source. The guy who wrote the FAT filesystem support has
> documented it some.
Is this available on a web site somewhere, because I can't find the
directory on my CD?
Thanks.
> It's interesting that to obtain documentation on Microsofts Operating
> Systems and file systems you have to come to Linux people for help.
That's cause Microsoft are poo. Anyway, I'm having trouble with
accessing the data from files and stuff, and I think looking at some
source code would clear up my confusion, and AFAIK the source to Windows
isn't available (yet!).
Adam.
------------------------------
From: Mario Klebsch <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why we are still holding on to X Windows
Date: Sun, 27 Jun 1999 14:42:20 +0200
Tristan Wibberley <[EMAIL PROTECTED]> writes:
>> And when it comes to consitency, the UNIX people alway dream about the
>> ability to choose amound hundreds of widget sets (Xaw, Xaw3d, Motif,
>> Lesstif, Gtk, Qt, ...), but in reality almos no one can choose. Only
>> the author of a program can choose, the user of a program cannot. He
>> has to live with the design decision, the autor took. And since each
>> author does his own decision, there is not much consistency among
>> different applications.
>Same for *ANY* computer system: Borland OWL, MFC, GTK, wxWindows, or any
>of the other toolkits available for windows, or even direct to GDI. The
>programmer decides, the user doesn't.
But mots windows libraries (they are not called toolkits in the windows
world) still ust windows native controls. That makes MFC so complicated,
because every GUI object exists twice, once as a C++ instance, and once
as a windows window, having its own window control procedure. Most
libraries in windows just pack the functionality of the windows control
and offer a C** binding for them.
X Tooltkits are completely different stuff.
>I think you are very confused
>about what an OS does. An OS does not stop application developers from
>choosing how to make their apps look - no OS does, not one, not UNIX,
>not MS Windows, not BeOS, not MacOS, none of them.
Believe me, I very well am aware of these problmes. But I also know,
that there are Macintosh User Interface Guidelines, and there is a
publication from Microsoft, called "The Windows Interface". There is
nothing like this for UNIX. Well, there is a Motif style guide, and
an open windows style guide and probably others, but none of them is
about UNIX or about X11.
This topic is just not covered by X11.
>Apps can only look
>the same because the person who wrote it decided to do that.
.. and because someone tried to define a standard and wrote it down,
so programmers can know about it.
73, Mario
--
Mario Klebsch [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (John E. Davis)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 27 Jun 1999 17:32:20 GMT
Reply-To: [EMAIL PROTECTED]
On 27 Jun 1999 04:00:39 -0700, Nathan Myers <[EMAIL PROTECTED]>
wrote:
>No. _None_ of the interesting aspects of C++ templates can be emulated
>with the preprocessor. See http://oonumerics.org/blitz/index.html .
It depends on what you call interesting. Consider vecmin.cc from
blitz which computes the minimum element of a vector. In C, I can
define a vector type (I am not claiming that any of this is pretty):
typedef struct Vector
{
unsigned int num_elements;
int type;
#define INT_TYPE 1
#define FLOAT_TYPE 2
.
.
#define DOUBLE_TYPE 3
void *data;
/* Methods */
void delete (Vector *);
int minvector (struct Vector *, void *);
.
.
}
Vector;
extern Vector *new_vector (unsigned int size, int type);
This can be used as:
Vector = *v;
int imin;
double dmin;
v = new_vector (100, INT_TYPE);
.
.
/* Now find min */
(void) v->minvector (v, &imin);
v->delete (v);
/* Do same with a vector of doubles */
v = new_vector (1000, DOUBLE_TYPE);
.
.
(void) v->minvector (v, &dmin);
v->delete (v);
The minvector method is provided by the following code:
#define FUN min_int
#define TYPE int
#include "minvector.inc"
#define FUN min_float
#define TYPE float
#include "minvector.inc"
.
.
#define FUN min_double
#define TYPE double
#include "minvector.inc"
Here, minvector.inc is:
/* minvector.inc */
int FUN (Vector *v, TYPE *value)
{
unsigned int i, imax;
TYPE m;
TYPE *data;
if (0 == (imax = v->num_elements))
return -1;
data = (type *)v->data;
m = data[0];
for (i = 1; i < imax; i++)
if (data[i] < m) m = data[i];
*value = m;
return 0;
}
#undef FUN
#undef TYPE
--
John E. Davis Center for Space Research/AXAF Science Center
617-258-8119 One Hampshire St., Building NE80-6019
http://space.mit.edu/~davis Cambridge, MA 02139-4307
------------------------------
From: [EMAIL PROTECTED] (John E. Davis)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 27 Jun 1999 17:35:02 GMT
Reply-To: [EMAIL PROTECTED]
On 27 Jun 1999 04:18:29 -0700, Nathan Myers <[EMAIL PROTECTED]>
wrote:
>Odd choice of example; Python is written in C++.
Since when? The last I check (about a month ago), it was still
written in C and there was some debate on the python newsgroup about
switching to C++.
--John
------------------------------
Date: Sun, 27 Jun 1999 18:31:24 +0200
From: Marc Mutz <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc
Subject: Re: Compilation errors with 2.2.10
maybe you forgot to make dep?
Marc
------------------------------
From: Robert Forsyth <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: Sun, 27 Jun 1999 17:38:33 +0000
Stefaan A Eeckels wrote:
>
> In article <7kvqc7$iht$[EMAIL PROTECTED]>,
> "Crist�bal Garc�a" <[EMAIL PROTECTED]> writes:
> >
> > Terry Murphy escribi� en mensaje <7kp9pq$9gg$[EMAIL PROTECTED]>...
[snip]
>
> > Another thing I've seen here is the old discussion about centralized
> > configuration (aka registry) vs. "distributed" configuration. I agree that
> > the centralized way is better than the distributed. Anyone could say that's
> > more error-prone but I think that you can implement a centralized
> > configuration with a lot of backup measures, ECC, etc in order to prevent
> > sys crashes. A good API to manipulate config from programs would help also.
> As with any (sub)system, you should ask whether the effort to build it
> is worth the expected benefits (a cost-benefit analysis is just as
> much part of the formal systems design process as a requirements
> analysis, BTW). In the case we're discussing (UNIX should have a central
> MS-Windows-like registry, and *all* programs ever written should be
> adapted to use it), moving from UNIX' existing approach is IMHO not
> worth it. You yourself indicate why:
> > you can implement a centralized configuration with a lot
> > of backup measures, ECC, etc in order to prevent
> [{my clarification} problems in case of]
> > sys crashes.
> IOW, *if* you use a central registry *then* you must do it properly,
> and use a good design, and a first class implementation. In addition
> (and this is an even bigger impediment), you must somehow *force*
> application designers to use it, which is all but impossible *unless*
> the facility offers so many advantages, is so flexible, fast etc
> that everyone will be convinced.
>
> It's unlikely that such a configuration library will show up any
> time soon, because (and this has been beaten to death before) a
> centralised approach is limited (eg, how to have an application's
> default configuration on a network).
>
> It's not because MS does something it's bad --but conversely, it's
> not because they do it that it's necessarily good either.
>
> > A last thing, I've worked also as sysman and If I've got out all the
> > software engineers out of my machines, probably I'd get fired 'cause my work
> > consisted on making computers usable to the soft desing/developing staff.
> >
I might have missed the point...
Isn't there "netinfo" in the Unix would, with command-line I/F and GUI,
its use always seemed to have the same disadvantages as MS registry,
huge binary file that can easily get corrupted, etc.
[snip]
--
Robert Forsyth
http://homepages.tcp.co.uk/~forsee/
tel/fax: +44 1243 787487
------------------------------
From: [EMAIL PROTECTED] (Chris Hedley)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why we are still holding on to X Windows
Date: 27 Jun 1999 17:34:14 GMT
In article <[EMAIL PROTECTED]>,
Mario Klebsch <[EMAIL PROTECTED]> writes:
> nothing like this for UNIX. Well, there is a Motif style guide, and
> an open windows style guide and probably others, but none of them is
> about UNIX or about X11.
I have a Motif Style Guide lying around somewhere. I can't find it at
the moment, but it's very large and heavy.
Chris.
------------------------------
Date: Sun, 27 Jun 1999 18:44:01 +0200
From: Marc Mutz <[EMAIL PROTECTED]>
Subject: Re: Trouble patching kernel 2.2.10
user wrote:
>
> Did anyone else have trouble applying the kernel patch 2.2.10?
>
> I started with 2.2.5 and appled 2.2.6, 2.2.7, 2.2.8, 2.2.9.
>
> Patch 2.2.10 failed.
>
> My version of patch is 2.1b.
>
You need at least patch v2.5.
Marc
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Can't export '/'
Date: Sun, 27 Jun 1999 17:55:23 GMT
David Yeung <[EMAIL PROTECTED]> wrote:
: I put an export entry in the /etc/exports file:
: / cozumel(rw,no_root_squash)
: and then run 'exportfs -a'. I get the following error:
: cozumel:/: Invalid argument
: Anyone knows why? Is it a security feature in order to
: disable exporting the root filesystem? If yes, how can
: I disable this security? I am running RH 6.0.
Does enabling CONFIG_NFSD_SUN in your kernel config help?
Jeff
------------------------------
** 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
******************************
