Linux-Development-Sys Digest #673, Volume #7 Sat, 11 Mar 00 13:13:15 EST
Contents:
Re: kernel in C++ ("Manish M")
To Linyx pl....help help ("Bass���v")
Re: kernel in C++ (David Wragg)
Re: kernel in C++ (Joe Pfeiffer)
Re: kernel in C++ (Alexander Viro)
Re: kernel in C++ (Mario Klebsch)
Re: kernel in C++ (Christopher Browne)
Starting a program in an iconic nxterm window? ("Norm Dresner")
Networking wierdness in 2.3.4? kernels (Richard Crew)
Re: kernel in C++ (Atle)
Re: kernel in C++ (Alexander Viro)
----------------------------------------------------------------------------
From: "Manish M" <[EMAIL PROTECTED]>
Subject: Re: kernel in C++
Date: Sat, 11 Mar 2000 11:16:13 -0500
I like your argument,
But this thread raises a question whether an OOP (language) is a suitable
language ?
I think the trend is moving towards OOP.
Also I have no contradictions to people's preference.
I believe, Linux is a big project and all those who are contributing are
respectable.
The point I am trying to make is that C++ is evolved through a lot of
research on the front of OOP/D
When the UNIX was written the OOP wasnt realised.
And the fact that trends are supporting, means it is being proven usefull.
Compared to a plain scripting/secuencial environment of progaming an object
based environment does give a lot of power at the high level which is
crusual for any OS to succede.
For example Microsoft gained a lot of leverage on its WindowXX by
introducing VB and VC++.
Once again I am posting these arguments only to support a certain thaught in
a certain direction. Whatever the development work people are doing is not
to be critisised (atleast from my side). I personally am a big fan of Linux
project too.
Thanx
Manish M
Christopher Browne <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Centuries ago, Nostradamus foresaw a time when Manish M would say:
> >I dont understand why is this such an issue. Aparently people are
> >looking it the wrong way.
> >
> >You DONT HAVE TO USE Every damn feature of C++ at every damn level.
>
> I'm *NOT* "looking at it the wrong way."
>
> Very little of what I said described severe technical challenges.
>
> Most of it described stuff that would *just plain be lots of boring
> work,* that the people working on "Linux in C" are likely reluctant to
> do.
>
> I *agree* that it does not make sense to use every feature of C++; in
> order to get *agreement* on which features *WOULD* be used, there
> would need to be some sort of "policy process" to enumerate and write
> down what is permitted and what is forbidden. That's an example of
> "lots of boring work" that provides, in and of itself, *no* new
> functionality.
>
> The most salient "resort to authority" is the following:
>
> "The Linux philosophy is laugh in the face of danger. Oops. Wrong
> One. 'Do it yourself.' That's it." -- Linus Torvalds
>
> If you want to redo the kernel in C++, DO IT YOURSELF.
>
> The critical three issues are _not technical_. They have to do with
> the _division of labour_.
> a) Redeploying Linux in C++ would involve a whole lot of work.
> b) It's not going to happen until somebody volunteers to _do_ that
> work.
> c) The people presently _actually doing work_ on Linux are
> sufficiently satisfied with C, and sufficiently busy, that they're
> not likely to be the volunteers to redeploy in C++.
>
> Some people wanted to add graphics support to the kernel (GGI), and
> made quite arrogant claims about the merits of the idea. I think they
> may have thought that once they came up with a proposal, that all the
> kernel people would magically drop everything, and say, "Cool idea!
> Let's just do this." That didn't happen; the people who wanted GGI
> *had to write it themselves.*
>
> Furthermore, Linus refused the initial patches, which was a GOOD THING
> because in the beginning, the GGI Project only had ideas, and not a
> clear understanding of how they would integrate in a friendly manner
> with the Linux kernel. They worked for quite a long time in parallel,
> and eventually the critical Framebuffer support bits have been
> integrated into the official development stream. A couple years
> later, mind you; but that seems to be a Good Thing.
>
> Similar things can be said about devfs, reiserfs, USB support, and
> probably a bunch of other facilities that have ultimately gotten added
> to the kernel.
>
> People Did It Themselves, and once what they had was stable, due
> consideration was made to whether or not it should be added to the
> "official" kernel tree.
>
> If you want "Linux-in-C++," then your mission is quite clear.
>
> _Start working on it._
>
> Linus Torvalds and Alan Cox and Alexander Viro and Stephen Tweedie and
> ... will essentially ignore you until you have a working
> implementation.
>
> You cannot expect Linus to see things your way until you clearly
> establish that it's feasible by virtue of having a *WORKING
> IMPLEMENTATION*. Working code trumps worthless blathering.
>
> _None_ of the above has said anything that should reasonably be
> construed as being derogatory of C++; sending out "nastygrams" about
> C++ is quite unnecessary. (Alexander Viro can feel free to add some.
> Bashing languages is fun and easy.)
> --
> Isn't it a bit unnerving that doctors call what they do "practice"?
> [EMAIL PROTECTED] - - <http://www.hex.net/~cbbrowne/lsf.html>
------------------------------
From: "Bass���v" <[EMAIL PROTECTED]>
Subject: To Linyx pl....help help
Date: Sun, 12 Mar 2000 00:30:46 +0800
hi
I'm using "Red Hat" now
I know how to share files and printer between "win" and "linux"
but ...
can I do this between "iMac (and other's apple ��) " and "linux" ???
How can I do this ???
THX THX
------------------------------
From: David Wragg <[EMAIL PROTECTED]>
Subject: Re: kernel in C++
Date: 11 Mar 2000 16:26:03 +0000
[EMAIL PROTECTED] (Christopher Browne) writes:
> Standards-conforming C and C++ programs run within an environment that
> starts *before* you start main(), and which terminate (if they *do*
> terminate) *after* main().
Not quite. The C standard defines two kinds of conformaing
implementation: Hosted and freestanding. A freestanding implementation
only has a subset of the standard library, and the entry point to the
program is impementation defined (i.e. no main).
David Wragg
------------------------------
From: Joe Pfeiffer <[EMAIL PROTECTED]>
Subject: Re: kernel in C++
Date: 11 Mar 2000 09:20:00 -0700
Atle <[EMAIL PROTECTED]> writes:
> I don't think anybody have really thought about it - but if you do think
> about it, you will come to the conclusion that unless the C++ compiler
> is drastically modified, it can't be used to write a kernel.
You're going to have to justify this claim: the GNU C++ compiler
would be very appropriate for writing a kernel; it supports in-line
assembler, so the few places where assembly is required can be
inserted as macros just like in C. What drastic modifications do you
see as necessary?
--
Joseph J. Pfeiffer, Jr., Ph.D. Phone -- (505) 646-1605
Department of Computer Science FAX -- (505) 646-1002
New Mexico State University http://www.cs.nmsu.edu/~pfeiffer
VL 2000 Homepage: http://www.cs.orst.edu/~burnett/vl2000/
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Subject: Re: kernel in C++
Date: 11 Mar 2000 11:33:21 -0500
In article <wZty4.9497$[EMAIL PROTECTED]>,
Manish M <[EMAIL PROTECTED]> wrote:
>> Sigh... So you never actually used them in C++. Hint: error deep in the
>> call sequence and you want to return to the caller of caller of... doing
>> required cleanups in each level. That happens in a lot of places. But the
>> reason why C++ exceptions are not going to fly is very simple - cleanups
>> are more complex than anything you can fit into the exception sematics.
>
>At the present level of C++ the objects are at a very high level that is why
>they have more overheads.
>Wait at kernel level if an error is deep where would you want to handle it ?
>But I think this argument only supports that C++ should be used right ?
What? Please, learn to read. It really helps. Understanding C++ might be
useful too... Look: there is a functionality that can be done both in C and
C++. C++ also has a mechanism that is close to what is needed (see above),
looks pretty, but is insufficiently flexible. Please, take any decent textbook
and learn what exceptions are, how they are implemented and when they are
used. Additional points for figuring out why they are insufficiently flexible
for typical situations in the kernel and why they are incompatible with
currently used mechanisms (which can be implemented both in C and in C++).
C++ is not a problem here. _Exceptions_ are.
>C++ gives you a way to atleast manage larger chunks.
>If you were to do the same things with functions with 12 arguments and
>struct's with 20-some elements including pointer attached with mallock-ed
>mem-blocks. How would you handle those ?
>(I know the answer by putting another global set of flags and some 100
>lines)
HUH? If you have a function with 12 arguments (in _any_ language) you can't
write. Period. Nothing nearly that horrible in the kernel. Ditto for global
flags. Please, take time to read the source. Otherwise I'm afraid that your,
erm, opinion on that subject is worth... well, not too much. Come on, you
don't know how to write in C, you have rather dim idea of C++, you didn't
even care to read the program you are talking about...
>> >static variable is a nice way to reutilize data, a global variable with
>> >automatic creation and deletion (can you do that in C ? without using any
>> >malloc or xyz_alloc).
>>
>> Damn. You do realize that if it can't be easily expressed in C you are in
>for
>> a lot of trouble implementing it? That permitted primitives for memory
>> allocation depend on the places where they will be used. Sigh...
>
>
>SIR
>
>that is what C++ is all about. C could do it too, but C++ manages it better.
>The approach you are indirectly suggesting me would need cryptic system
>level code
>(full of pointers & reference problems).
WHAT IT IS ABOUT? About the requirements regarding ability to block in the
given context? About the difference between upper half and bottom half?
About the fact that allocating memory on IO path not from the constant pool
is a bad idea because resulting swapping may trivially lead to dealocks?
Complexity is not in syntax. And no, compiler doesn't have enough information
to choose the correct behaviour - C++ was never intended to be used in that
kind of tasks.
>> Bullshit. Absolute bullshit. Go to dmr's site and read through the C
>compiler
>> circa '73. You can't get closer to beginning. Source is there, read it.
>
>C existed before '73 my dear. And UNIX was born in Bell labs in 1969.
>here is the URL if you need more info
>http://vertigo.hsrl.rutgers.edu/ug/unix_history.html
Wow. How lovely... To start with, UNIX was rewritten into C in v4. Before that
kernel was in PDP-11 assmebler (and before that - in PDP-7 assembler). FYI,
guy in question (dmr, that is) has some relation to history of both C and
UNIX. He is author of the former and co-author of the latter. Feel free to
correct him, indeed... URL in question: http://www.cs.bell-labs.com/~dmr
>> >Thanx My dear web-mates
>> ???
>> You know, it's not Web, it's USENET...
>
>Its all "web" (WORLD WIDE WEB) my friend. If it is not, then USENET isnt
>much anyway without it.
My dear retard, I hate to break it on you, but World Wide Web is not the
same as the internet - it's a subset. Please, read the fucking RFCs and avoid
using the words if you don't know what they mean.
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: [EMAIL PROTECTED] (Mario Klebsch)
Subject: Re: kernel in C++
Date: Sat, 11 Mar 2000 10:29:16 +0100
[EMAIL PROTECTED] (Christopher Browne) writes:
>It seems to me that it would be vastly more sensible for the people
>that want to create an OS in C++ to *START THEIR OWN PROJECT.*
That probbaly is the best aproach. And there are other issues to
handle: The system call API is a very traditional procedural API. For
an object oriented OS using a kernel written in C++, I would expect an
object oriented API to the kernel. This API would (and should) be
incompatible to the current linux system call interface.
73, Mario
--
Mario Klebsch [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Subject: Re: kernel in C++
Reply-To: [EMAIL PROTECTED]
Date: Sat, 11 Mar 2000 17:19:41 GMT
Centuries ago, Nostradamus foresaw a time when Manish M would say:
>I like your argument,
>
>But this thread raises a question whether an OOP (language) is a
>suitable language ?
C++ is *not* an "OOP language." Stroustrup does not describe it that
way; you really should look at his FAQ. The use of C++ does *not*
mandate OO techniques; it merely provides some "syntactic sugar" to
support certain OO techniques.
>I think the trend is moving towards OOP.
The *hype* had been "moving towards OOP" for some years now. These
days, the hype seems to be "moving towards XML."
If you want to be With The Latest Hype, you *should* be promoting the
idea of putting XML parser/generator code into the kernel so that
input and output would be done in XML. [What would Linus' reaction be
to that, Alexander?]
Note that the Linux kernel *already uses* object oriented programming
techniques.
>Also I have no contradictions to people's preference.
>
>I believe, Linux is a big project and all those who are contributing are
>respectable.
>
>The point I am trying to make is that C++ is evolved through a lot of
>research on the front of OOP/D
>
>When the UNIX was written the OOP wasnt realised.
The C++ model is largely based on what was in Simula. You might want
to do some research as to when Simula was created.
[Hint: It wasn't in the 1970s...]
>And the fact that trends are supporting, means it is being proven
>useful.
No, it merely means that marketers are having good success at selling
Dilbertian managers on the merits of the ideas. Whether the ideas
themselves have merit is a whole other question.
>Compared to a plain scripting/secuencial environment of progaming an
>object based environment does give a lot of power at the high level
>which is crusual for any OS to succede. For example Microsoft gained
>a lot of leverage on its WindowXX by introducing VB and VC++.
Microsoft "gained a lot of leverage" by spending a lot of money on
marketing, and by spreading Fear, Uncertainty, and Doubt about
competitors.
"It is better to have 100 functions operate on one data structure
than 10 functions on 10 data structures." -- Alan Perlis
Object-based environments tend towards *vast* proliferations of
different kinds of data structures. Which *diminishes* the "power at
the high level," since you have to have a specific method to deal with
every operation you want to apply to every object.
In contrast, with UNIX, at the user level, "everything's just a file
or a process." Indeed, it is readily argued that UNIX is already
extremely object oriented, with the caveat that the objects aren't
what the theoreticians of Smalltalk consider to be objects.
>Once again I am posting these arguments only to support a certain thaught in
>a certain direction. Whatever the development work people are doing is not
>to be critisised (at least from my side). I personally am a big fan
>of Linux project too.
Who are you trying to convince of what?
If you're trying to convince the people developing the Linux kernel to
use C++, then you're in the wrong forum, doing the wrong things.
"You think you know when you can learn, are more sure when you can
write, even more when you can teach, but certain when you can
program." -- Alan Perlis
The way to convince them to use C++ is to provide a (rather large!)
patch that makes Linux compile using C++, and *show* them that your
opinions have merit by showing them that your opinions *work.*
When you blather here about how you think you want to
"support a certain thaught in a certain direction,"
that does absolutely nothing for your "cause" except to show that you:
a) Probably don't know as much about the relative merits of C, C++,
and object-oriented programming as you *think* you do,
b) Don't know that in order to discuss this *usefully,* you'd have to
discuss it on the kernel mailing list, and
c) Don't know that results are the only coin of real value here.
--
Isn't it a bit unnerving that doctors call what they do "practice"?
[EMAIL PROTECTED] - - <http://www.hex.net/~cbbrowne/lsf.html>
------------------------------
Reply-To: "Norm Dresner" <[EMAIL PROTECTED]>
From: "Norm Dresner" <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.programmer,comp.windows.x
Subject: Starting a program in an iconic nxterm window?
Date: Sat, 11 Mar 2000 17:30:13 GMT
I am in the process of developing an embedded (real-time) linux system and
one of the programs that needs to be started when the system is initialized
simply needs to run in an nxterm window -- so that any error messages from
the startup can be read -- but thereafter really runs with no user
intervention and no screen output.
I tried to execute it with the command
nxterm -T DISP -iconic -e /jsf/cue/dispatcher/dispatcher
but the program refused to start until the window was restored from iconized
to normal size. I have since done some experimenting with simplified
versions, finally reducing it to test programs that contained only these
forms:
a) fprintf( stderr , ...
b) fprintf( stdout, ...
c) fopen( logfile , "w" ); fputs( ... ); fclose(...);
d) open( logfile , O_CREAT | O_WRONLY) ; write( .. ) ; close( ...);
and none of these test programs proceeds to do any I/O at all until the
window is restored.
The questions, then, are:
1) Can *any* program start without access to an initial window?
a) if so, what limitations would prevent it from doing so?
b) if so, is there any way to get "log" output to a file or the
"window" while it's iconized?
2) Is this an anomaly based on nxterm? Would other windows behave
similarly?
For the record, the system is RH 5.2 (and rtl 0.9J) with XFree86 v 3.3.2.3
All suggestions are appreciated.
Norm
------------------------------
From: [EMAIL PROTECTED] (Richard Crew)
Subject: Networking wierdness in 2.3.4? kernels
Reply-To: [EMAIL PROTECTED]
Date: Sat, 11 Mar 2000 17:46:21 GMT
Every since kernel 2.3.40, networking has been sluggish to non-existent
on my machine (I exclude a few kernels that didn't even compile). Has anyone
else seen this behavior?
At the moment, I'm running 2.3.51, and even such things as 'telnet
localhost' seem to hang, as do ftp and ping. Curiously, I'm able to read
news, and 'route' seems to show what one expects. 'netstat' hangs if I'm
reading news, and shows *nothing* if I'm not.
This is all with glibc-2.1.3 and net-tools 1.50, running ppp 2.3.11, and all
the ppp modules seem to be loaded. Have I made some bizarre config error, or
is this a kernel bug?
--Rich
[EMAIL PROTECTED]
Oh, and here's the relevant part of the kernel config:
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y
#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_NETLINK=y
CONFIG_RTNETLINK=y
# CONFIG_NETLINK_DEV is not set
# CONFIG_NETFILTER is not set
CONFIG_FILTER=y
CONFIG_UNIX=y
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_IP_ROUTER is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_ALIAS is not set
# CONFIG_SYN_COOKIES is not set
#
# (it is safe to leave these untouched)
#
CONFIG_SKB_LARGE=y
#
#
#
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_DECNET is not set
#
# Network device support
#
CONFIG_NETDEVICES=y
#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set
# CONFIG_DEPCA is not set
# CONFIG_NET_ISA is not set
# CONFIG_NET_PCI is not set
# CONFIG_NET_POCKET is not set
#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_SK98LIN is not set
# CONFIG_FDDI is not set
# CONFIG_PLIP is not set
CONFIG_PPP=m
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
CONFIG_SLIP=m
CONFIG_SLIP_COMPRESSED=y
CONFIG_SLIP_SMART=y
CONFIG_SLIP_MODE_SLIP6=y
#
# Network File Systems
#
# CONFIG_CODA_FS is not set
CONFIG_NFS_FS=y
# CONFIG_ROOT_NFS is not set
CONFIG_NFSD=y
# CONFIG_NFSD_V3 is not set
CONFIG_SUNRPC=y
CONFIG_LOCKD=y
# CONFIG_SMB_FS is not set
# CONFIG_NCP_FS is not set
--
Better to toss a stone at random, then a word.
-Porphyry
------------------------------
From: Atle <[EMAIL PROTECTED]>
Subject: Re: kernel in C++
Date: Sat, 11 Mar 2000 19:11:54 +0100
Joe Pfeiffer wrote:
>
> Atle <[EMAIL PROTECTED]> writes:
>
> > I don't think anybody have really thought about it - but if you do think
> > about it, you will come to the conclusion that unless the C++ compiler
> > is drastically modified, it can't be used to write a kernel.
>
> You're going to have to justify this claim: the GNU C++ compiler
> would be very appropriate for writing a kernel; it supports in-line
> assembler, so the few places where assembly is required can be
> inserted as macros just like in C. What drastic modifications do you
> see as necessary?
The I will have to retract that immediately, like I said, I havent'
really thought about it. What sprung to mind were virtual functions,
multiple inheritance, and lack of overview of what code is actually
produced.
But, of course, when the code is inline assembly, you know exactly what
the compiler produces, and you would probably never use virtual
functions for kernel code.
I did hear about 'object assembler' in the early 90's, so there is
absolutely nothing in the object-orientation itself that is not suited
for very low level programming. It is enough that one person claims to
be able to write a kernel in C++, and I will agree that it is possible.
One of the reasons I didn't think of it, is that I don't see what you
would gain from it.
During the design phase, yes, but I would use assembly/C for the
implementation.
Atle
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Subject: Re: kernel in C++
Date: 11 Mar 2000 12:43:05 -0500
In article <[EMAIL PROTECTED]>,
Christopher Browne <[EMAIL PROTECTED]> wrote:
>If you want to be With The Latest Hype, you *should* be promoting the
>idea of putting XML parser/generator code into the kernel so that
>input and output would be done in XML. [What would Linus' reaction be
>to that, Alexander?]
C|N>M
Damn! Dunno about Linus, but now I'll have to clean the thing. You know,
putting C&C warnings is a good idea...
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
** 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
******************************
