Linux-Development-Sys Digest #672, Volume #7 Sat, 11 Mar 00 11:13:15 EST
Contents:
Re: kernel in C++ ("Manish M")
Re: kernel in C++ ("Frank V. Castellucci")
Re: kernel in C++ (Christopher Browne)
Re: Kernel Module Problem (orion22) (Christian Winter)
Re: How to re-create a boot disk (Christian Winter)
debug network device driver (Wu man777)
Re: kernel in C++ ("Frank V. Castellucci")
Re: kernel in C++ ("Manish M")
----------------------------------------------------------------------------
From: "Manish M" <[EMAIL PROTECTED]>
Subject: Re: kernel in C++
Date: Sat, 11 Mar 2000 10:08:46 -0500
The main() is the strrting point of C, is true by definition.
But the definition for a language does not define loading rules.
They are outside the scope of language definition.
For you information : Kernel also is loaded by BIOS and ther is an
environment before kernel.
So a main can be created to be loaded from BIOS.
Why the compilar work like they work is because the makers are focused to a
particular market. the compiler makers wouldnt make something for 3 or 4
copy worth of market.
If you want to be purists then it is arguable that a compiler dosnt have to
be written to loade progs in certain way by language definitions.
Christopher Browne <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Centuries ago, Nostradamus foresaw a time when Mark Hahn would say:
> >> You can't write a kernel in C++ or C. That is to say, if you take
> >> the ISO C or C++ standard and stick to the language features
> >> described there, you won't get anywhere.
> >
> >this is quite wrong, since it assumes that there are hardware constructs
> >that can't be addressed with standard-conforming C. that assumption is
> >certainly true for some hardware, but not necessarily all possible
hardware.
>
> No, you can't write a kernel in standards-conforming C or C++.
>
> 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().
>
> The standards only speak to what happens once you get to main(); they
> do not provide the "boot up" environment in which the programs run.
>
> With C, this means that programs *normally* depend on there being this
> little library called "crt.o" or "gcrt.o" linked in to provide the
> environment in which main() can run. These libs are about 1K in size;
> they provide small, but crucial services.
>
> With Objective C, the equivalent appears to be objcrt.a, which, on
> Linux, appears to be about 55K of code to support Objective C
> messaging.
>
> With C++, there does not appear to be a direct equivalent; it appears
> to leap straight to the Standard C++ Libraries, replete with exception
> handlers, iostreams, and such.
>
> At any rate, the given is that you *have* to have code that lies
> outside the standards in order to supply an environment in which
> "standard" code can execute. With C, that "outside" code is quite
> tiny, so that there isn't much that lies between ordinary C and "the
> real world" outside. With C++, the "environment" needs to be vastly
> larger...
> --
> When you awake, you will remember nothing of what I have told you.
> [EMAIL PROTECTED] - - <http://www.ntlug.org/~cbbrowne/lsf.html>
------------------------------
Date: Sat, 11 Mar 2000 10:27:58 -0500
From: "Frank V. Castellucci" <[EMAIL PROTECTED]>
Subject: Re: kernel in C++
Christopher Browne wrote:
>
> Centuries ago, Nostradamus foresaw a time when Frank V. Castellucci would say:
> >Dieter Stueken wrote:
> >>
> >> Bernd Strieder wrote:
> >> > You say crap, but this crap has been designed to make
> >> > programmers life easier, ...
> >>
> >> but not the kernel life :-)
> >>
> >> With this discussion we easily can fill up a discussion group
> >> of it's on (is there some group already?). This C++ discussion
> >> came up again and again with no result. Yes, many things might
> >> be expressed much much clearer using C++, but it is simply
> >> impossible for several reasons: Who is willing to rewrite the
> >> whole kernel in C++? If you start now, it would take years to
> >> do that and to test it and find all bugs you will introduce.
> >> Meanwhile the original kernel will continue to develop much
> >> faster than your C++ project, you will never overhaul it.
> >> Even if all programmers, including Linus himself, will stop using
> >> C and turn to C++ this means, that all development of linux will
> >> stop for years too. Its really hard to accept, but the C train
> >> runs too fast, to jump off now without beeing killed.
> >>
> >> So it's right to refuse the statement: "all parts of the kernel
> >> schould be recoded in C++ using all language features", but
> >> on the other hand, it is silly to refuse any goods of C++
> >> due to some bad properties of C++, like exceptions, which
> >> are in fact absolutely unusuable within a linux kernel
> >> environment. Also the statement "C++ is too buggy to be
> >> taken into account" will not hold for ever.
> >>
> >> The question should be: under which circumstances would it
> >> be possible to introduce C++ into the kernel? There are big
> >> parts which are not dealing directly with hardware or interrupts,
> >> i.e. the filesystem parts. If you once have interfaces and wrapper
> >> classes around the kernel structures you can start testing C++
> >> without affecting the inner kernel construction. If it turns out
> >> to be usuable, you may have a change to convert the inner kernel
> >> routines step by step in the far future.
> >
> >I disagree on the FUD factor layed on here. While I agree it would not
> >be a trivial undertaking I would consider that one of the fundemental
> >requirements would be to preserve the API, which could be easily done.
> >There are synchronized issues between current Linux in asm and C, and
> >with Linux in asm and C++.
>
> What "FUD factor" are you talking about?
I don't know how you missed the first paragraph but:
> >> be expressed much much clearer using C++, but it is simply
> >> impossible for several reasons: Who is willing to rewrite the
> >> whole kernel in C++? If you start now, it would take years to
> >> do that and to test it and find all bugs you will introduce.
> >> Meanwhile the original kernel will continue to develop much
> >> faster than your C++ project, you will never overhaul it.
> >> Even if all programmers, including Linus himself, will stop using
> >> C and turn to C++ this means, that all development of linux will
> >> stop for years too. Its really hard to accept, but the C train
> >> runs too fast, to jump off now without beeing killed.
"Take years" is speculative at best, "will never overhaul it" as well.
There are more than five C++ developers out here who would participate
(including myself). And the assumption that all development of linux
will STOP for years had me completely amazed. Can you<rhetorical you>
say parallel development?
> And:
> >> Also the statement "C++ is too buggy to be taken into account" will
> >> not hold for ever.
> is not what someone trying to "FUD" C++ would say.
Without qualifying what the "bugginess" is? Would you accept that as an
answer from a team member?
> >Is it the right thing to do? If you lecture about why NOT instead of
> >ISSUES and HOW-TO we may never see it. What ever happened to
> >encouragement? If nobody encouraged Linus (through participation) our
> >choices would be the various general processing OS would be limited.
> >
> >A C++ interface, and abstraction of key parts is quite desirable.
>
> It's desirable *to you.*
Only me? Lets be a little bit realistic here. I know another guy...
> It's manifestly clear that it is *NOT* desired by the people that
> write kernel code.
>
> <http://www.tux.org/lkml/#s1-4> provides some comments not dissimilar
> to those above...
As I said, there are operating systems that, with the exception of the
machine dependent assembler code, are object oriented. It is a wonderful
model to work with. Until you have fully immersed yourself in OO it is
hard to grasp the value it brings to the table.
I myself started with BAL/370 (years), moved to Motorola
Assembler(years), then x86 Assembler(years), the C(years), and
C++(years). In addition I have done enough work in Smalltalk, Java, and
OCCM to consider myself proficient.
The only issues then become ones of optimized machine code generation,
and side effects of the language. C++ is by far and away the more mature
of the OO languages I have listed. Would I promote a OO Linux for a
80386 machine, probably not, but if done right the overhead differences
between the current kernel and a WELL DESIGNED AND IMPLEMENTED C++ image
would be barely distinguishable from a performance perspective.
>
> The point are thus:
>
> 1. Transforming Linux to C++ would be a Substantial Task.
> 2. Time of breakage.
> 3. Merely Recompiling in C++ is worthless.
> 4. There are parts of C++ that would be troublesome.
> 5. Which Subset of C++ Should Get Picked?
> Note that all five of the above matters need to be resolved before you
> get a functioning kernel. In effect, in order to get something that
> might still be buggy, there's a huge amount of design work that would
> have to be done.
I agree that it would not do to get it to compile with a C++, or merely
port the existing base. Your other points are present in almost every
development effort.
> I think it could *easily* take a year or more for there to be a
> faintly usable result.
I would never hazard a guess as to time without understanding the
requirements or resources to address the problem. For that matter, the
problem needs to be fairly well stated before anything is done.
> 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.*
Maybe this is the crux of the reaction to the suggestion, I don't think
anyone said "Tell Linus to STOP what he is doing and do THIS!" I think
the suggestion was part question part testing the water. There have been
many responses where I am sure someone sat back and with a smug grin on
their face thought "I showed them!", and this is a sad thing. While, to
your merit, you have enumerated some of the issues that need to be
faced, there are mounting <flames> instead of solutions.
>
> You want to write an OS kernel in C++?
>
> _Feel free._
I would give up
> You want to use Linux 2.3.something as the initial code base?
>
> _That's AOK. The Linux kernel uses the GPL, and thus you're free to
> do that._
>
> If you can attract a bunch of other people to work with you, _that's
> great._
>
> If, two years from now, you have a usable kernel, and it is fast
> enough and stable enough that people want to use it rather than Linux,
> it would be fair to offer congratulations.
>
> BUT.
>
> The people working on Linux are doing so in C, and prefer it that way.
> And enough have enough experience with this that they're arrogant (and
> somewhat justifiably so) enough to not care what some newcomer
> blathering about C++ says.
>
> You go write "C++nix", and when you get it working, you'll have enough
> technical authority to tell them some merits and demerits of using C++
> for the purpose from other than a purely academic perspective.
And some of this is not FUD? If not insultive?
--
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Subject: Re: kernel in C++
Reply-To: [EMAIL PROTECTED]
Date: Sat, 11 Mar 2000 15:26:26 GMT
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: Christian Winter <[EMAIL PROTECTED]>
Subject: Re: Kernel Module Problem (orion22)
Date: Sat, 11 Mar 2000 12:40:55 +0100
Francisco Obispo schrob:
> Im currently writing a character device driver for a serial board that
> a friend is developing... my problem is that when I try to write to the
> por 0x301, using writeb(0x8f,0x301); It does it too fast for the decoder
> to notice this change... so I was reading and found out that slow boards
> use outb_p but when I use this function, I get no errors at compile time
> but then I get unresolved symbol outb_p when I try to load the module...
>
> Any Ideas???
With some test-modules I made I had the same problem, which
could be solved by turning on gcc switch -DEXPORT_SYMTAB
HTH
Christian
--
|~-_ /~~~~~ Free Linux Portal: http://www.linux-config.de ~~~~~\ _-~|
| // de.etc.schreiben.* - Usenet-Literatur im www: \\ |
| // http://www.usenet-autoren.de \\ |
|_||[EMAIL PROTECTED]http://www.thepoet1.de__||_|
------------------------------
From: Christian Winter <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux.mandrake,comp.os.linux.misc
Subject: Re: How to re-create a boot disk
Date: Sat, 11 Mar 2000 15:00:40 +0100
Tony Wiegand schrob:
> the second disk has linux installed. I'm running Mandrake 6.0. When I
> installed Mandrake, LILO had a problem. So I re-installed windows into
> the Master boot record and booted to linux with the boot disk. Now my
> boot disk is screwed up and I can't get back to Linux.
> I tried downloading the boot.img from Red Hat, but it just tries to do a
> re-install of the OS.
Maybe the first disk of smalllinux could help you. It boots a tiny
disk-only only linux, but at the prompt you can give it the harddrive
partitions to mount. This way you could get into your mandrake and
recreate your boot disk from there. smalllinux is downloadable from
the internet.
HTH
Christian
--
|~-_ /~~~~~ Free Linux Portal: http://www.linux-config.de ~~~~~\ _-~|
| // de.etc.schreiben.* - Usenet-Literatur im www: \\ |
| // http://www.usenet-autoren.de \\ |
|_||[EMAIL PROTECTED]http://www.thepoet1.de__||_|
------------------------------
From: [EMAIL PROTECTED] (Wu man777)
Subject: debug network device driver
Date: 11 Mar 2000 15:32:57 GMT
Hi there:
I am working on a network device driver using RH 6.0.
I try to push a IP/UDP packet to the IP stack and see if it can be picked
up by a server. The IP packet has 127.0.0.1 as the both source/dest addr,
the UDP header has 0x1111 and 0x2222(just for testing) as source/dest port
number, with no checksum.
The driver does:
/* allocate a skb_buff */
/* copy a dummy e-header with IP protocol type */
/* copy the dummy packet to skb_buff using skb_put() */
skb->dev = myadp->dev; // setup the device pointer
skb->protocol = eth_type_trans(skb, myadp->pkt_type);
skb->ip_summed = CHECKSUM_UNNECESSARY;
netif_rx(skb);
myadp->stats.rx_packets++;
Somehow the UDP server never see the packet. My log file doesn't show
any error message from the kernel. I dump the skb->data after the
eth_type_trans() and it has the right data in there(without the e-header).
Where does the packet go ? What went wrong ? How can I look into the IP
stack ? Checksum error ?
Any suggestion are wellcome,
thanks,
By the way, the dummy IP packet is:
0x45, //ver 4, 5 words
0,
0,
52,
0x39,
0x62,
0,
0,
1,
0x11, // UDP protocol
0x82,
0x55,
127,
0,
0,
1,
127,
0,
0,
1,
0x11, // UDP source port
0x11,
0x22, // UDP dest port
0x22,
0,
8+24,
0x00,
0x00
<24 bytes chars>
------------------------------
Date: Sat, 11 Mar 2000 10:39:46 -0500
From: "Frank V. Castellucci" <[EMAIL PROTECTED]>
Subject: Re: kernel in C++
Christopher Browne wrote:
>
> You want to write an OS kernel in C++?
>
> _Feel free._
In my first response I posted without completing the sentence. What was
intended was:
I would gladly give up all other work if I was funded to undertake a C++
Linux OS opportunity.
And there is a word that no one has used.
--
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
------------------------------
From: "Manish M" <[EMAIL PROTECTED]>
Subject: Re: kernel in C++
Date: Sat, 11 Mar 2000 10:51:01 -0500
Alexander Viro <[EMAIL PROTECTED]> wrote in message
news:8admtc$[EMAIL PROTECTED]...
> In article <eksy4.9445$[EMAIL PROTECTED]>,
> Manish M <[EMAIL PROTECTED]> wrote:
> >I would love to see somethig like
> >disk.dir.file.open
>
> ??? Parse it, please. No, not the syntax, just tell what you want here.
> Files do not belong to directories, for one thing.
>
> >or
> >device1.buffer =device2.buffer
>
> Again, what meaning do you want here? There is no such thing as buffer of
> device. There is a request queue. What semantics would you assign to "="
> here?
>
I dont understand in this scruplour and meticulous world of "USENET" why
people ignore details.
I mentioned the word "like" and wanted to convay a sense of programing
showing that if the objects are there with there respective heirarchy then
it is a lot easiar to model,manage, remember,write code,& modify. That is
what a modern programing environment is supposed to give. A proper OOP based
OS would represent the enteties inside the kernel or the entire OS
systamatically. If you have a closer model of the enteties then you have a
stronger and efficient way to manage them. That is what OOP is all about.
SIR.
> >or
> >screen.window.buffer = network.machine_id.disk.file
>
> HUH? What "window"? It's a kernel, damnit.
>
> Look: there are objects in the kernel. All VFS and VM are built that way.
> But could you please learn what it does and what objects are there
_before_
> deciding which tools are more suitable for the thing?
>
> >By the way ! at kernel level why would you want to have exception
handling
> >anyway ? Exception are to be thrown against a higher level code
> >(application) by a Low level (OS) back to the Highlevel (application).
If a
> >piece of Kernel meets an exception like situation whome do you think it
> >should tell ? and who do you think should throw the exception at first
place
> >?
>
> 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 ?
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)
> >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).
> >By the way UNIX was written mainly in C and that is where C was really
> >shaped, because it is based on the architecture of assembly, where you
can
> >link functions same way as you would insert macros of assembly code.
>
> IOW, you don't know assembly. Or C history, for that matter.
>
> >Original C does not have more than 32 keywords because all the work is
done
> >through those assembly blocks and then other C blocks/functions created
from
> >those assembly based code. So C itself is a bunch of assembly code with
> >other code being simply permutation and combination of those basic
blocks. C
> >was created as just a scripting language for those blocks of code.
> >Compiler/linker for scripting and linking those blocks.
>
> 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
> >Now if you just add a layer of Classes to the same concept of C, it is
not
> >going to change anything at low level simply because C++ DID NOT REPLACE
ANY
> >C it only added to it.
>
> Yes, and apparently it generates a lot of kids who have no idea of the
> cost of features, not to mention such arcane things like "what it actually
> compiles to?"
>
> >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.
==============
Those who think they know really know, annoy us who really know. ---- some
like mmmmmmm well.
> --
> All that blue light from Orthanc at night? That was Saruman, trying to
> moderate news.admin.palantir-abuse.sightings.
> Mike Andrews in the Monastery
==============
Those who think they know everything, really annoy us who really know it
all. ---- some like mmmmmmm well.
------------------------------
** 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
******************************
