Linux-Development-Sys Digest #856, Volume #6 Mon, 21 Jun 99 19:14:36 EDT
Contents:
current->timeout (Lee John Keyser-Allen)
Re: using C++ for linux device drivers (Don Waugaman)
Re: IDE card crashes kernel 2.2.x not 2.0.36 (bill davidsen)
Re: You can now use Winmodems in Linux!!!!!!! (Frank v Waveren)
Re: using C++ for linux device drivers (Frank Sweetser)
re: Intercepting Ethernet Frames? ("Paxton Smith")
Re: TAO: the ultimate OS (Vladimir Z. Nuri)
Re: TAO: the ultimate OS (Peter Samuelson)
Re: Problem! (jwk)
Re: [CONTRACT] kernel programming tutorials (Frank v Waveren)
Re: using C++ for linux device drivers (Nathan Myers)
Module Address Space ("James Oldroyd")
----------------------------------------------------------------------------
From: Lee John Keyser-Allen <[EMAIL PROTECTED]>
Crossposted-To: linux.dev.kernel
Subject: current->timeout
Date: Mon, 21 Jun 1999 17:30:46 -0400
I'm attempting to implement a simple loop to wait on a piece of hardware
to wakeup. Since it's part of the initialization code, it's not
increadibly time-critical i.e. a difference of a jiffy or so isn't a big
deal, so in order to be nice to the system I was going to try to make a
loop that'll delay a jiffy or so each iteration.
I attempted to use the sample code from Rubini's Linux Device Drivers
book, based around current->timeout, but it appears that in recent kernels
(2.2.x) timeout has been removed from the task_struct structure. If there
is an easy way to make this go, or something I'm over looking, please let
me know, I'm currently just spinning in a loop with schedule(), so it's
not *that* bad and it's only for 600ms tops but ...
Any help is appreciated.
Thanks,
Lee
========================
Lee Keyser-Allen
--([EMAIL PROTECTED])
========================
------------------------------
From: [EMAIL PROTECTED] (Don Waugaman)
Subject: Re: using C++ for linux device drivers
Date: 21 Jun 1999 11:20:19 -0700
Disclaimer: While I'm enthusiastic about C++, I recognize that there's
a heck of a lot of folks who don't care for it and emphatically don't wnat
it in the kernel. I think that they're wrong, though there is a lot of
truth to the points they make. However, I'll try to clear up some
misconceptions given below.
In article <[EMAIL PROTECTED]>,
Frank Sweetser <[EMAIL PROTECTED]> wrote:
>"John Burton" <[EMAIL PROTECTED]> writes:
>
>> Frank Sweetser wrote in message ...
>> >Justin Vallon <[EMAIL PROTECTED]> writes:
>> >
>> >> Too bad. All you should need is:
>> >>
>> >> void *operator new(size_t s) { return malloc(s); /* kmalloc, etc */ }
>> >> void operator delete(void *p) { free(p); }
>> >
>> >...which is a higher-overhead version of
>> >
>> >#define new((x)) malloc((x))
>> >#define delete((x)) free((x))
>>
>> No it isn't, it is very different. malloc and free don't construct the
>> objects
>> they just alllocate the memory.
>
>yup. but, then, neither do the versions written as non-inline functions up
>above. mine also has this flaw, but at least it ends up as a bit of inline
>code rather than another function call on every new/delete...
Your '#define' hack given above is rather broken. I'll try to explain
how this works in C++. Briefly, the 'operator new' function has but one
thing to do - allocate memory - while the new operator does two things,
allocate memory (by using operator new) and call the class constructor.
When you have a line in C++ which allocates dynamic memory such as
NetworkCard* c = new EthernetCard;
two things happen: first, operator new is called to allocate the memory
and then the class constructor (in this case, the default constructor)
is called to construct the object.
There are three different possibilities for the operator new function:
1) You can define a class-specific 'operator new' function which will
allocate memory for all objects of that class.
2) You can define a global 'operator new' function which will allocate
memory for all objects of classes which don't have a class-specific
operator new. This is what Justin shows above.
3) You can do nothing and use the default definition in the compiler's
runtime, which will work OK for application programs but not inside
the kernel.
The redefined operator new that Justin gives above only does memory
allocation, and that's all that operator new has to do.
Notice also that your #define solution above won't work because new
expressions don't have to be of the form 'new(class)' - and, IIRC,
can't be. This method will create some rather strange results if one
uses 'new (nothrow)' which is what should be used in the kernel anyway
if one uses the new operator.
--
- 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..." | <><
The Bible tells us to love our neighbors, and also to love our enemies;
probably because they are generally the same people. -- G. K. Chesterton
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Subject: Re: IDE card crashes kernel 2.2.x not 2.0.36
Date: 21 Jun 1999 21:49:10 GMT
In article <[EMAIL PROTECTED]>,
Sander Grendelman <[EMAIL PROTECTED]> wrote:
| I've got some weird vlb cached IDE controller (don't even know the
| brand)
| When I trie to boot Linux, of a hd attached to it, or even try to use
| the SuSe 6.1 bootdisk, the kernel crashes at the moment it tries to
| do the partition check: PTBL: [512/64/63] <1 Oops kernel null pointer
| dereference ....
Try putting in the disk hardware configuration info on the boot line
(C/H/S) and see if the BIOS is giving bad info.
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
The Internet is not the fountain of youth, but some days it feels like
the fountain of immaturity.
------------------------------
From: [EMAIL PROTECTED] (Frank v Waveren)
Subject: Re: You can now use Winmodems in Linux!!!!!!!
Date: Mon, 21 Jun 1999 22:59:06 GMT
In article <[EMAIL PROTECTED]>,
Kevin Burton <[EMAIL PROTECTED]> writes:
> Cool.. I am for it!
>
> Can we change the name to LinModems?
Can we change the name to hoax? This is some guy who thinks he's funny,
there are currently no winmodem drivers for linux :-(
--
Frank v Waveren
[EMAIL PROTECTED]
ICQ# 10074100
------------------------------
From: Frank Sweetser <[EMAIL PROTECTED]>
Subject: Re: using C++ for linux device drivers
Date: 21 Jun 1999 14:43:31 -0400
[EMAIL PROTECTED] (Don Waugaman) writes:
> Disclaimer: While I'm enthusiastic about C++, I recognize that there's
> a heck of a lot of folks who don't care for it and emphatically don't wnat
> it in the kernel. I think that they're wrong, though there is a lot of
> truth to the points they make. However, I'll try to clear up some
> misconceptions given below.
>
> In article <[EMAIL PROTECTED]>,
> Frank Sweetser <[EMAIL PROTECTED]> wrote:
> >"John Burton" <[EMAIL PROTECTED]> writes:
> >
> >> Frank Sweetser wrote in message ...
> >> >Justin Vallon <[EMAIL PROTECTED]> writes:
> >> >
> >> >> Too bad. All you should need is:
> >> >>
> >> >> void *operator new(size_t s) { return malloc(s); /* kmalloc, etc */ }
> >> >> void operator delete(void *p) { free(p); }
> >> >
> >> >...which is a higher-overhead version of
> >> >
> >> >#define new((x)) malloc((x))
> >> >#define delete((x)) free((x))
> >>
> >> No it isn't, it is very different. malloc and free don't construct the
> >> objects
> >> they just alllocate the memory.
> >
> >yup. but, then, neither do the versions written as non-inline functions up
> >above. mine also has this flaw, but at least it ends up as a bit of inline
> >code rather than another function call on every new/delete...
>
> Your '#define' hack given above is rather broken. I'll try to explain
yes, i know. so are the functions which were mentioned in the post
previous to mine. read the whole thread. basically, it was "well, you can
just do new and delete with these two wrapper functions to malloc and
free!" and i said "well, if you're going to do eye-candy functions like
that, at least do 'em this way to avoid another function call." i'm well
aware that in real C++, the new and delete operators are much more involved
than a simple malloc and delete.
--
Frank Sweetser rasmusin at wpi.edu fsweetser at blee.net | PGP key available
paramount.ind.wpi.edu RedHat 5.2 kernel 2.2.5 i586 | at public servers
"Captain, you are an excellent Starship Captain, but as a taxi
driver you leave much to be desired." --Spock
------------------------------
From: "Paxton Smith" <[EMAIL PROTECTED]>
Subject: re: Intercepting Ethernet Frames?
Date: Mon, 21 Jun 1999 16:43:44 -0500
Hi all,
I would like to modify the ethernet frame and
it's contents before it is sent up the protocol
stack, however, I don't want to be tied to a
particular vendor's NIC. In the WinNT world,
this is accomplished with and NDIS driver -
VxWorks accomodates this by allowing you
to simply hook a function to an ethernet frame
arrival. How is it done with Linux? That is,
is there a mechanism in place for this type
of thing?
Thanks in advance,
Paxton Smith
------------------------------
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
From: [EMAIL PROTECTED] (Vladimir Z. Nuri)
Subject: Re: TAO: the ultimate OS
Date: Mon, 21 Jun 1999 22:31:51 GMT
Paolo Torelli ([EMAIL PROTECTED]) wrote:
: MY target is to gather informations, help, suggestions, critics,
: eventually finding people that can actually help building the project
: better and faster.
mine too!!
My hope is that all possible flaws in the project can
: be discovered and corrected before being too late.
"too late"?? imho there is all the time in the world.
I'm patient. there is no deadline esp. on an open
source project supported by volunteers and
not being driven by budget constraints. and linux had many
years to develop.
My goal is to gain
: consensus and blesses from a wide area of people, possibly
: programmers/designers/whatever so that the project can count on a base
: to build up. This is what I'd like to do.
I think much of this thread shows the "community" is not so interested
in consensus, and not so much "building up" something as
tearing it down. this is clearly what I set out to obtain in good
faith & all the posts support it.
: Now, what have you done so far? I came and read a couple of messages
: (the earlier were expired), and my impression was that you did all the
: possible to turn people against the project.
this is common in this thread & elsewhere: someone
complaining about my or other's posts without citing anything
specific. well my posts & others tend to be like rorschach tests, I've noticed.
ppl read whatever they want into them. I wrote those posts, and it is
quite absurd, imho, to suggest I was doing "all that is possible to
turn ppl against project"!! hahaha. quite to the contrary.
I am very tired of ppl who criticize my posts
without actually citing any lines. any kind of
picture whatsoever can be created by spin artists in followup posts.
if you QUOTE where I was out of line, I'll reconsider.
the criticism of my proposal by respondents is falling into a few specific
bins which I don't find very fair, and it is typically
rephrased in only minute variations. I find it all very
tedious & repetitive. and I'll respond with a bit
of brashness in my response if the flameurs provoke it..
1. "you have no code."
I know!! I don't claim to!! code starts from memes!!
2. "it is a waste of time to post without code"
I will post whenever I feel like it, and I have in fact contributed
by developing the essay alone.
3. "we don't know who you are. why should we listen?"
the essay speaks for itself. I will not post a resume.
4. "you are a crackpot."
maybe, maybe not<g> again, I prefer to let essay speak
for itself.
5. "no one will follow"
I am not looking for followers. and the ideas may be developed
regardless of my own interest in the matter.. I have some confidence
in this happening.
6. "you think you're galileo"
I think I have successfully articulated key features of the future
OS. and I don't think Galileo ever programmed as far as I know<g>
7. "what you are asking for is impossible."
how so? I beg to differ. no one has nailed down at all how
what I am calling for is impossible. perhaps ppl do not want to
admit that existing OSes are flawed not because of inherent
difficulties but "blind spots & bugs in human psychology"
(particularly the programmers creating OSes)
8. "show us everything now, or you're a bozo/loser"
I am not at that point yet. the essay calls for a collaborative
approach. rather than challenging me, every single person here could
have contributed to fleshing out the ideas in the essay.
9. "you haven't told us exactly what an object is".
there are already several object-based OSes out there. it is
doable. I'm not asking for something radically different.
I think every one of my posts shows I will be civil to those
who return the favor of civility. I will not attempt to be civil
to those who abandon all pretense of civility. fair enough?
evolutionary strategy, "tit for tat". the only reason I am writing
so much here, in regard to your typical nebulous criticism, is that
I take civility very seriously, and imho far more so than most
in cyberspace!!
if I didn't care, I would have stopped posting a long time ago,
I assure you. I see positive signs there is more attn on the
goals mentioned in the essay.
What I saw were people
: saying their opinion and their suggestions, noticing flaws in your
: messages, and I also say you replying to those same messages with an
: such an attitude! Do you believe you did well in your efforts? I tried
: to put on-board an essay which could possibly give better results, and I
: was people flaming me because of what you said before.
ah, I see, so if anyone cannot make progress toward the goals cited
in the essay, it is my fault, and if you encounter any hostility,
it's because I've taunted people who would otherwise help. that
people are not helping or contributing so far solely because of my
attitude problem. hahah pardon me while I ROFL.. plz reread the
thread and reconsider your historical revisionism and naivete about
human psychology embodied & fossilized in it like bugs in amber!!
Now, how can
: possibly someone have faith in a project when its members are against
: the whole world? And my message in which I pointed you what you were
: doing bad should have been enough for you to understand.
: 'nuff said.
faith is not necessary. simple rationality will do just fine.
"against the whole world?" hahaha that reminds me of andy grove's
saying, "only the paranoid survive"<g> go ahead and criticise
me because I don't back down, even in the face of widespread
hostility!! I am working with memes that ultimately transcend
popularity contests, although not in the short term.<g>
--
~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
"in theory, there's no difference [EMAIL PROTECTED]
between theory and practice, mad genius research lab
but in practice there is!" http://www8.pair.com/mnajtiv/
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 21 Jun 1999 14:07:35 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Terry Murphy <[EMAIL PROTECTED]>]
> Look at ODBC in Windows: because of this additional feature, the
> system is suddenly more flexible. You can plug any database backend
> into your program without changing a line of code. THAT is flexible.
> How could this flexibility be achieved in a system with no notion of
> a database?
I think you are missing Linus's point -- when he refers to the OS
design as flexible, he doesn't mean you can't have things like ODBC.
He means that ODBC will be a shared library, not a system call.
Good example: user authentication. In the old days, authentication was
done via /etc/passwd and /etc/group, with a little input from
/etc/shells, and behold, this was inflexible. Someone somewhere
invented shadow passwords to improve security, someone else somewhere
else invented YP, then had to rename it NIS, then beefed up its
security somewhat and called it NIS+, then eventually someone got the
idea that authentication needed to be even more flexible and
configurable and created PAM.... And yet. Through this entire
evolution, not *one* single line of kernel code has had to be changed.
(Excluding maybe some network provisions cf. NIS, etc.) Any of these
systems will work fine on a modern Unix system, and only userspace
libraries and binaries have to care -- because it is *entirely* a
userspace problem. Unix is flexible in that it was designed with a lot
of *entirely* userspace problems.
If you have something sufficiently well understood to codify into a
sensible API, there's no reason that API needs to be kernel-based.
When it's not, you gain the advantage of easily dropping in newer
versions of the library, complete with newer versions of the API,
relatively easily and with *no* fear of breaking old code, since the
two versions can coexist. (At least on most Unices.)
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (jwk)
Subject: Re: Problem!
Date: 21 Jun 1999 19:03:57 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 21 Jun 1999 15:43:18 +0200, Michele <[EMAIL PROTECTED]> wrote:
>Hi there,
>I have a big problem which i can't figure it out.I have made a program
>running under linux v.2.0.27 that acts as a client for a server programs
>that runs over the same machine.It is designed as a main loop that never
>exits and beyond sending messages to the server,uses the /dev/mem to
>access the memory below 1M.It works fine for some days but suddenly it
>stops running(disappear!!) and I don't have any clue about the reason
>why.Is there a way to keep track of what has happened to it?Is there the
>possibility that the linux kills the program for some reasons?I know
>that informations I am giving aren't of such help but any suggestions
>are kindly accepted.
>Thanks
>Michele
Use gdb to see where it exits, or strace to see what it's doing.
Good luck,
Jurriaan
--
For who are we to question her
Who stands among the stones
Big Country - The Seer
------------------------------
From: [EMAIL PROTECTED] (Frank v Waveren)
Subject: Re: [CONTRACT] kernel programming tutorials
Date: Mon, 21 Jun 1999 23:01:33 GMT
In article <[EMAIL PROTECTED]>,
Gary Lawrence Murphy <[EMAIL PROTECTED]> writes:
>
> We need experienced kernel programmers to explain Linux 2.2/2.3 to an
> intermediate/advanced programmer audience. Our goal is to spark
> development of new device support (like Winmodems! ) and to inspire
> new programmers to join the kernel project. It doesn't pay big, but
> this is a paid gig for a LI member, and you're free to fold what you
> write back into LDP docs. If you're interested, please let me know.
Sorry, I don't have the experience, but where can I sign up for the lectures?
:-)
--
Frank v Waveren
[EMAIL PROTECTED]
ICQ# 10074100
------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Subject: Re: using C++ for linux device drivers
Date: 21 Jun 1999 12:27:56 -0700
Frank Sweetser <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Nathan Myers) writes:
>> Frank Sweetser <[EMAIL PROTECTED]> wrote:
>> >Justin Vallon <[EMAIL PROTECTED]> writes:
>> >> [EMAIL PROTECTED] (Alexander Viro) writes:
>> >> void *operator new(size_t s) { return malloc(s); /* kmalloc, etc */ }
>> >> void operator delete(void *p) { free(p); }
>> >
>> >...which is a higher-overhead version of
>> >
>> >#define new((x)) malloc((x))
>> >#define delete((x)) free((x))
>>
>> Frank, you are confused beyond salvation on this point.
>> Best drop it.
>
>exactly how am i confused? (honest question, i'm not trying to flame...)
The new operator in C++ is not (normally) called as a function,
so your macros would just break code. The argument to it is
a type, not a number, so it cannot be passed to malloc. It
calls a constructor. In allocation, it has different semantics
from malloc. Need I go on?
>> >> Compile with -nostdinc++ -fno-exceptions.
>> >>
>> >> Static constructors may need a C++ link phase, or you could warn that
>> >> C++ static constructors will not be executed.
>> >
>> >don't forget about name mangling, call by reference, the whole
>> >private/public/protected mess...
>>
>> Name mangling is dealt with by 'extern "C"'.
>
>hrm... IIRC, there were some issues that came up with the last time this
>matter got hashed out regarding exporting symbols from C++ code - ie, going
>the other way. i may be misremembering, though...
Yes.
>> Call-by-reference is a non-issue; no kernel function or callback uses it.
>
>another feature of C++ that can't be used.
Works fine within the C++ code.
>> There is no such thing as a "private/public/protected" mess.
>> Those keywords have no effect on the emitted object code.
>
>another feature of C++ that can't be used.
Works fine within the C++ code.
>> That they are keywords at all might break some kernel headers.
>
>i guess my biggest point here is - once you take away all of the extra
>features that won't work or don't make sense in the kernel context, what
>advantages does C++ realy have for writing a kernel module?
Better error checking. Better expressiveness. If you don't know
C++, this won't mean anything to you. If you do know C++, those
qualities are wrenching to give up.
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
From: "James Oldroyd" <[EMAIL PROTECTED]>
Subject: Module Address Space
Date: Mon, 21 Jun 1999 18:33:57 -0400
How does the Kernel Handle loading modules into a calling applications
address space. Is there a good source of information about the ?Loader? on
the net?
James
------------------------------
** 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
******************************
