Linux-Development-Sys Digest #671, Volume #7 Sat, 11 Mar 00 10:13:15 EST
Contents:
MP3 Players Other Than Rio (Christopher Browne)
Re: kernel in C++ (Kaz Kylheku)
Number of Pseudo Terminal ? ("Jaron Chou")
Re: kernel in C++ (Alexander Viro)
Re: How to re-create a boot disk ("Michel J. Vos")
Workr From Home Opportunity (Brian)
Re: kernel in C++ ("Manish M")
Re: kernel in C++ (Atle)
Re: kernel in C++ (Alexander Viro)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.hardware
Subject: MP3 Players Other Than Rio
Reply-To: [EMAIL PROTECTED]
Date: Sat, 11 Mar 2000 05:32:33 GMT
Are there any of the portable MP3 players available in North America
aside from the Diamond Rio that can happily communicate with Linux
systems?
--> The Pontis SP503
<http://www.pontis.de/site_e/produkte/pl_503_e_htm> is a German
product that appears somewhat Europe-oriented. (What's 230 Euro in
USD?)
My agenda is rather oriented towards the question of whether any
support is known of for the RCA Lyra. It supports CompactFlash cards,
with rather more potential capacity than the 32MB (expandable to 64MB)
of most of the players that are available now.
[Further agenda: I accidentally wound up with a 64MB CompactFlash
card, and wouldn't mind finding it useful for something...]
--
Appendium to the Rules of the Evil Overlord #1: "I will not build
excessively integrated security-and-HVAC systems. They may be Really
Cool, but are far too vulnerable to breakdowns."
[EMAIL PROTECTED] - - <http://www.hex.net/~cbbrowne/lsf.html>
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: kernel in C++
Reply-To: [EMAIL PROTECTED]
Date: Sat, 11 Mar 2000 06:00:08 GMT
On 11 Mar 2000 02:20:37 GMT, Mark Hahn <[EMAIL PROTECTED]>
wrote:
>
>> 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.
The standard defines no access to hardware constructs other than the
abstractions provided by the standard library. You can't even implement the
standard library in standard C, not to mention an entire OS.
Accessing memory mapped hardware is beyond the language; to do that you have to
create pointers to arbitrary addresses which results in undefined behavior.
><long sermon against C++ omitted>
Nonsense; I was only trying to explain that using C++ in kernel programming is
possible, but faced with certain surmountable difficulties---namely the need
to retarget certain run time support features. Definitely not a sermon against
C++.
--
#exclude <windows.h>
------------------------------
From: "Jaron Chou" <[EMAIL PROTECTED]>
Subject: Number of Pseudo Terminal ?
Date: 11 Mar 2000 06:22:17 GMT
Hi,
I am seraching for a function to get the
number of pseudo terminal on the system ?
Is there one ?
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Subject: Re: kernel in C++
Date: 11 Mar 2000 02:03:31 -0500
In article <[EMAIL PROTECTED]>,
Frank V. Castellucci <[EMAIL PROTECTED]> wrote:
>Mark Hahn wrote:
>>
>> > A C++ interface, and abstraction of key parts is quite desirable.
>>
>> mere syntactic sugar.
>
>A typical response.
No, the typical responce to your ilk is different. Here:
*PLONK*
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: "Michel J. Vos" <[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 13:03:02 +0000
Tony Wiegand wrote:
>
> Here's my story. I have to disks, the first disk has windows installed
> and
> 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.
>
> Any help would be appreciated.
You can start Linux from DOS with loadlin. Should be on the distro cd...
------------------------------
From: Brian <[EMAIL PROTECTED]>
Subject: Workr From Home Opportunity
Date: Sat, 11 Mar 2000 13:00:30 GMT
I have an immediate position opening with my client for a
DEVICE DRIVER DEVELOPER.
You can work from your own home.
This is an exceptional opportunity.
If you have previous experience writing device drivers in any of the
following categories, please contact me immediately.
Audio Device Drivers (WDM preferred)
2D or 3D Video Device Driver Experience (Windows, or Linux, or Unix)
Network Device Drivers (Windows, or Vxworks, or Unix, or ATM,
or NDIS, or bluetooth, or Sonet/SDH)
RTOS Embedded Systems Experience (x86, or Hitachi, or SH3, or MIPS)
You have nothing to loose and everything to gain.
My client is a well-established very respected company in the industry.
This is a full time position, with salary and complete company
benefits.
I will be more than happy to give you details, if you contact me.
Don't be shy!
Contact me.
All information and correspondence will be kept strictly confidential.
==============================
Contact me for more details.
Mailto:[EMAIL PROTECTED]
==============================
------------------------------
From: "Manish M" <[EMAIL PROTECTED]>
Subject: Re: kernel in C++
Date: Sat, 11 Mar 2000 08:58:41 -0500
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.
C++ has about 3 levels of programming. All ment for different context. I can
have a class, (C++), with a function,(C), with assembly, (C-- :), code
inside it.
Use C++ features for larger objects where the high level rules are to be
defined. Hey guys do you think JAVA is a mistake.
I would love to see somethig like
disk.dir.file.open
or
device1.buffer =device2.buffer
or
screen.window.buffer = network.machine_id.disk.file
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
?
Expception and other stuff had been added to provide ready to go packages
(to which all are spoiled to, including me). Which can be implemented in C
using different techniques. Actually all those tools existed in C also only
in different forms, which were lengthy or not ready-made.
What is a run time system. You use the ready made features which are just
given to you by a library. In C it just a statically liked library, which is
not much but a set of functions created out of the same basic assembly
blocks, working under.
"static" was actualy a relief to me because I found that I can have
confined+global functions. It was nice to see that those function are
bundled togather and not just hanging around. Additionally they could access
encapsulated data but be available just like C function along with being a
part of a class, without having to spawn/instantiate an object.
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).
If you look at the genetics of C++ it is pure C only with on more more layer
of management that is Classes. It is not very late to those days that
preprocessors used to convert C++ code to C and compile it in C.
Actually purely speaking even Event programming is NOT A PART OF C++. Thats
why Microsoft had to write macros calles message maps. And Borland had to
deviate from specs by making ret_type class::Foo() = xyz;. Which was not
accepted as an extension to C++ later by ANSI. Basically an external call, &
direct invoking of a non static member function of a class is against the
basic idea of objects and encapsulation. Event programing is a characterstic
of OS not language and C++ had to simply bend itself to adopt.
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.
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.
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.
Thanx My dear web-mates
Manish M
Christopher Browne <[EMAIL PROTECTED]> wrote in message
news:J3ky4.339$[EMAIL PROTECTED]...
> 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?
>
> There were none of the (typical) salacious comments about C++ being
> "evil, bad, and bloated."
>
> 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.
>
> >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.*
>
> 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...
>
> The point are thus:
>
> 1. Transforming Linux to C++ would be a Substantial Task.
>
> If I hazarded a guess, the task of merely redeploying it to
> *compile* using G++ would be liable to be a six month task, and be
> problematic.
>
> 2. Time of breakage.
>
> For the time during which the transformation is taking place, there
> would be a considerable period of time during which the kernel
> would be BROKEN. Not "a bit buggy;" not "with a few flaws."
> BROKEN. As in CANNOT COMPILE.
>
> 3. Merely Recompiling in C++ is worthless.
>
> It makes *no* sense to go through the effort of making it work
> using G++ and *not* do some substantial redesign to take advantage
> of C++ language features.
>
> 4. There are parts of C++ that would be troublesome.
>
> new, vtables, and exceptions represent merely three of the things
> where C++ expects to have some "external environment" out there to
> manage things for it. These things would have to be
> "bootstrapped."
>
> This is a bit worse than with C.
>
> 5. Which Subset of C++ Should Get Picked?
>
> Using the whole thing, with bits arbitrarily picked for use, would
> be fairly disastrous.
>
> But the process of building up a "policy document" of what bits of
> C++ must, and must not, be used, would add a further task, and
> would be highly flameworthy.
>
> 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 think it could *easily* take a year or more for there to be a
> faintly usable result.
>
> 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.*
>
> You want to write an OS kernel in C++?
>
> _Feel free._
>
> 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.
> --
> The only problem
> with Haiku is that you just
> get started and then
> [EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/lsf.html>
------------------------------
From: Atle <[EMAIL PROTECTED]>
Subject: Re: kernel in C++
Date: Sat, 11 Mar 2000 15:31:05 +0100
Saurabh Shrivastava wrote:
>
> hi everybody,
> people say, kernel cant be written in C++. Is it true ?
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.
But the philosofy behind C++ can even be very useful when designing a
kernel, you can 'imagine' that a specially made C++ compiler supports
writing kernel code, this will help you in developing the different
parts of it, the microkernel, the virtual memory system and allocation,
deallocation, garbage collection, the IPC structures, etc.
One book that I have found to give a good understanding of how
object-thinking and kernel development goes together, is Operating
Systems - A Design Oriented Approach by Charles Crowley. As you read
about the different parts of the kernel, you sort of 'imagine' a C++
compiler that you could use to build this kernel.
So the answer is: Yes. It is true that a kernel can't be written in C++.
But it would have been nice.
Atle
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Subject: Re: kernel in C++
Date: 11 Mar 2000 09:57:48 -0500
In article <eksy4.9445$[EMAIL PROTECTED]>,
Manish M <[EMAIL PROTECTED]> wrote:
>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.
>
>C++ has about 3 levels of programming. All ment for different context. I can
>have a class, (C++), with a function,(C), with assembly, (C-- :), code
>inside it.
>
>Use C++ features for larger objects where the high level rules are to be
>defined. Hey guys do you think JAVA is a mistake.
Java is less bloated, but yes, it _is_ a mistake in many cases. It's definitely
used _way_ out of its natural domain, mostly because PHBs (who know squat about
C, C++, Java, etc.) heard that "Java is The One True Way". I've seen a lot of
Java code that could be trivially rewritten into C, shrinking to 10% of
original size, becoming much cleaner and running in minutes instead of hours.
There are situation when Java is the right tool, but it's not a universal
thing. Same for C++.
Please, try to realize that there is no such thing as Object Oriented Langauge.
There is Object Oriented Programming, but that's totally different beast - it's
about the idioms you are using.
>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?
>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.
You simply don't have objects that would be naturally associated with
resources you have to release, etc. You could create artificial ones, but
then you would get really nasty code and a lot of overhead.
>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...
>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.
>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...
--
All that blue light from Orthanc at night? That was Saruman, trying to
moderate news.admin.palantir-abuse.sightings.
Mike Andrews in the Monastery
------------------------------
** 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
******************************
