Linux-Development-Sys Digest #328, Volume #8 Wed, 6 Dec 00 22:13:11 EST
Contents:
Re: Module Compilation Problems ([EMAIL PROTECTED])
Re: kernel header problems ([EMAIL PROTECTED])
Re: floating point in kernel... (Rick Ellis)
Re: Deamons (Rick Ellis)
Re: Getting the CPU load value in a LKM... (Rick Ellis)
Re: How to make a BIOS call in Linux (Jonathan Buzzard)
Re: kernel header problems (Kaz Kylheku)
crt1.o (Damon Jacobsen)
Re: c++ in kernel and linker problems ("O.Petzold")
Re: c++ in kernel and linker problems ("O.Petzold")
Re: kernel header problems ([EMAIL PROTECTED])
Re: c++ in kernel and linker problems ([EMAIL PROTECTED])
A faster memcpy and bzero for x86 (Boris Gjenero)
Attention NYC Shoppers & Visitors - Beware of Rip-off SY Stores!!! ......
epDwMLBUS5MC ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Module Compilation Problems
Date: Wed, 06 Dec 2000 19:46:45 GMT
Peter T. Breuer <[EMAIL PROTECTED]> wrote:
>> Of course, the fact that Linus recommends _not_ linking from
>> /usr/include into the kernel tends to carry alot of weight with most
>> people.
> Why should linus recommend so? I imagine he simply doesn't want kernel
> headers at all in the include hierarchy, thus decoupling kernel and
> libraries completely. That's an OK goal. But ...
The various reasons are in the lkml archives. I didn't mean to argue
relative merits of the link, however. I was just pointing out that the
fact that Linus doesn't use it, and recommends noone else does either
is a compelling reason to dump the idea.
It's a shame that the kernel headers continue to cause problems, such
as last weeks post about being unable to ls long files on Debian
systems on lkml.
>> And again, since in RH 7.0 you have the option of installing either a
>> 2.2 or 2.4 test kernel, multiple trees are an issue.
> But apparently the problems caused for people who now can't compile
> their third party modules aren't? Yet another instance of "if you're on
> redhat, you can't compile"? No thank you. Gimme the symlink.
No, if you install either the 2.2 or 2.4 kernel, you'll have the
matching headers.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: kernel header problems
Date: Wed, 06 Dec 2000 19:58:32 GMT
Kaz Kylheku <[EMAIL PROTECTED]> wrote:
>>/usr/src/linux/include/linux/signal.h:159: warning: assignment of negative
>>value `-1' to `long unsigned int'
> There is nothing wrong with this assignment. To anyone with half a clue in
> C or C++ programming, it's a familiar idiom for the maximum value of the
> unsigned type. I find warnings like this to be extremely annoying.
> Just ignore it.
You could make the argument that i = ULONG_MAX; is a familiar idiom
for the maximum value of an unsigned type as well. That being the
case, the compiler is perfectly justified in warning about the other
as a potential error.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Rick Ellis)
Subject: Re: floating point in kernel...
Date: 6 Dec 2000 20:13:54 GMT
In article <9031b0$pmm$[EMAIL PROTECTED]>,
Perego Paolo <[EMAIL PROTECTED]> wrote:
>Hi guys, I know that I can't use floating point in my kernel module but
>I need to calculate a thing like system load.
You don't need floating point to do that calculation. Scaled integers
should work just fine if you pay attention.
--
http://www.spinics.net/linux
------------------------------
From: [EMAIL PROTECTED] (Rick Ellis)
Subject: Re: Deamons
Date: 6 Dec 2000 20:38:30 GMT
In article <[EMAIL PROTECTED]>,
Lew Pitcher <[EMAIL PROTECTED]> wrote:
>> /* Close low fd's and reopen as /dev/null */
>> for(i=0; i < 3; i++) {
>> close(i);
>> open("/dev/null", O_RDWR, 0);
>> }
> /* move to root directory */
> chdir("/");
I'd also use reopen instead of close+open:
freopen("/dev/null", "r", stdin);
freopen("/dev/null", "w", stdout);
freopen("/dev/null", "w", stderr);
--
http://www.spinics.net/linux
------------------------------
From: [EMAIL PROTECTED] (Rick Ellis)
Subject: Re: Getting the CPU load value in a LKM...
Date: 6 Dec 2000 21:34:25 GMT
In article <908fhq$r3q$[EMAIL PROTECTED]>,
Perego Paolo <[EMAIL PROTECTED]> wrote:
>Hi guys, it's me again! :) In my kernel module I'm writing, I need to
>know the CPU load value calculated by the kernel. Linking timer.c file
>in my module I think isn't the right things so, how can I have exported
>for my module this value.
unsigned long avenrun[3] = { 0,0,0 };
--
http://www.spinics.net/linux
------------------------------
From: [EMAIL PROTECTED] (Jonathan Buzzard)
Subject: Re: How to make a BIOS call in Linux
Date: Wed, 6 Dec 2000 21:27:42 +0000
In article <[EMAIL PROTECTED]>,
Josef Moellers <[EMAIL PROTECTED]> writes:
[SNIP]
> As to the APM code, I don't know, but I'll make an educated guess: the
> APM is a fairly recent development and, as such, the APM BIOS is
> available in a protected mode version. Also, I guess, it's highly
> vendor-specific, so rather than write several versions of APM code,
> Linux can very well use the APM BIOS.
It is because it is highly vendor and laptop/chipset dependent. The
original APM specification which is a Microsoft world thing was back in
the days of DOS/Windows 3.x and is a real mode thing as well. The idea
was to just add extra BIOS calls to make it all happen. Standard parctice
at the time.
The kernel also seems to call the BIOS to do with the PCI bus, try booting
a kernel with PCI enabled on a non PCI machine to see what I mean. Though
this is proper 32 bit protected mode stuff.
JAB.
--
Jonathan A. Buzzard Email: [EMAIL PROTECTED]
Northumberland, United Kingdom. Tel: +44(0)1661-832195
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: kernel header problems
Reply-To: [EMAIL PROTECTED]
Date: Wed, 06 Dec 2000 22:34:32 GMT
On Wed, 06 Dec 2000 19:58:32 GMT, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>Kaz Kylheku <[EMAIL PROTECTED]> wrote:
>>>/usr/src/linux/include/linux/signal.h:159: warning: assignment of negative
>>>value `-1' to `long unsigned int'
>
>> There is nothing wrong with this assignment. To anyone with half a clue in
>> C or C++ programming, it's a familiar idiom for the maximum value of the
>> unsigned type. I find warnings like this to be extremely annoying.
>> Just ignore it.
>
>You could make the argument that i = ULONG_MAX; is a familiar idiom
>for the maximum value of an unsigned type as well. That being the
>case, the compiler is perfectly justified in warning about the other
>as a potential error.
What handy constant shall I use if that unsigned type is size_t?
------------------------------
From: Damon Jacobsen <[EMAIL PROTECTED]>
Subject: crt1.o
Date: Wed, 06 Dec 2000 13:50:29 -0800
Has anyone else noticed serious degradation in preformance in the
latest
builds of crt1.o? I am using Red Hat 7 and noticed that crt1.o is
causing my code to come to a crawl unless I bring over a version of it
from SUSE 6.1. I noticed some compilers are coming with thier own
verision of it and was wondering if anyone had the source code for this
file and knew why we were seeing performance degradation.
Damon
------------------------------
From: "O.Petzold" <[EMAIL PROTECTED]>
Subject: Re: c++ in kernel and linker problems
Date: Wed, 06 Dec 2000 17:38:09 +0100
>
> > So I can use dynamic_cast and typeid (typeinfo.h) ?
Well,: if(a->type() == b->type()) { // is the same
this way is gone before rtti ? It's a question of the std, since is rtti
inside ?
>
> > > > The nothrow symbol is defined inside header new with extern const
> > > >nothrow_t nothrow;
> > > Thats a declaration, not a definition. Are you sure that nothrow is
> > >defined somewhere?
> >
> > Yes, in my code - see above: char* p = new(nothrow) char[39]; With
> > this I can proof on (!p) for user and kernel space. The other way
> > could
>
> I still can't see any definition.
Well, maybee my overloaded operators ?:
void* operator new(size_t size, const std::nothrow_t&)
{
return mem = kernel_allocate(size);
}
void operator delete(void* ptr, const std::nothrow_t&)
{
kernel_deallocate(ptr);
}
void* operator new(size_t size)
{
return ::operator new(size, std::nothrow_t());
}
void operator delete(void* ptr)
{
::operator delete(ptr, std::nothrow_t());
}
void* operator new[](size_t size)
{
return ::operator new(size, std::nothrow_t());
}
void operator delete[](void* ptr)
{
::operator delete(ptr, std::nothrow_t());
}
------------------------------
From: "O.Petzold" <[EMAIL PROTECTED]>
Subject: Re: c++ in kernel and linker problems
Date: Wed, 06 Dec 2000 17:50:01 +0100
>
> You cannot use components from the C++ standard library in the kernel;
> that library is not available. Only a very small subset of the C library
> is there, never mind C++.
The subset is once the other is the nightmare of mixing c++ and kernel
includes ... I'm using rtlinux, where I don't get any mixed headers trough
the compiler. It fails at stl_alloc.h with
#ifdef __STL_PTHREADS
template <bool __threads, int __inst>
pthread_mutex_t
__default_alloc_template<__threads, __inst>::_S_node_allocator_lock
= PTHREAD_MUTEX_INITIALIZER;
#endif
which will be expanded to:
template <bool __threads, int __inst>
pthread_mutex_t
__default_alloc_template<__threads, __inst>::_S_node_allocator_lock
= { 0,0,1, (spinlock_t) { } , PTHREAD_MUTEX_DEFAULT, { 0 } ,
PTHREAD_PRIO_NONE } ; //581
/usr/lib/gcc-lib/i386-redhat-linux/2.95.2/../../../../include/g++-3/stl_alloc.h:581:
parse error before `}'
/usr/lib/gcc-lib/i386-redhat-linux/2.95.2/../../../../include/g++-3/stl_alloc.h:581:
excess elements in aggregate initializer
> You will find that even if you thrown your own exception type, it will not
> work. You see, exception handling requires considerable run-time support, int
> the form of special functions that are in libgcc.a. This would have to be
> ported to the kernel. So unless you are willing to do that work, you can
> forget about C++ exception handling in the kernel.
How does it work in principle. At moment I use a global var.
> Also do you really need RTTI? In well structured code, certainly the kind of
Not really. It was for interesting .
> A bigger problem you are facing is the rampant use of C++ keywords in the
> kernel's header files: class, namespace, public, you name it.
>
> My recommendation is that you make a header "hidekeywords.h" which defines
> macros that have the same spelling as C++ keywords, and expand to identifiers
> which are not C++ keywords, e.g:
>
> #define class cpp_class
> #define virtual cpp_virtual
I'v done. new ist the problem with the list from kernel.
>
>
> Also create another another header which #undefs all these macros, so that you
> can do, at the top of your C++ file:
>
> #include "hidekeywords.h"
> extern "C" {
> #include <linux/kernel/headers.h>
> }
> #include "restorekeywords.h"
>
> >How can I write the classes nothrow, exception
> >and
> >bad_alloc so that I don't get linker errors ?
>
> Since you don't have exception handling, you have no use for these. Write your
> operator new so that it just returns null when there is no memory and use
> traditional error handling.
I use in kernel space only the what() member function, see prior posting. I guess
therfore I have the symbol in my module.
Thanks Olaf
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: kernel header problems
Date: Thu, 07 Dec 2000 00:52:27 GMT
Kaz Kylheku <[EMAIL PROTECTED]> wrote:
> What handy constant shall I use if that unsigned type is size_t?
SIZE_MAX.
Yes, it's not part of any standard that I'm aware of, but I consider
that an oversight. SSIZE_MAX is standard, and having one without the
other is idiotic, in my view.
Of course mbstowcs(3) is required by the C standard to return a
size_t, which is -1 on error. So, there's plenty of idiocy with this
particular type going around.
I wonder, will casting it the way the mbstowcs() return value is
supress the compiler warning?
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED]
Reply-to: [EMAIL PROTECTED]
Subject: Re: c++ in kernel and linker problems
Date: Thu, 07 Dec 2000 01:03:13 GMT
>>>>> "M.Waack" == O Petzold <[EMAIL PROTECTED]> writes:
M.Waack> Mathias Waack wrote:
>> "O.Petzold" <[EMAIL PROTECTED]> writes:
>> > Further more I use in the source char *p = new(nothrow)
>> char[39] > if(!p) { > THROW(std::bad_alloc); }
>>
>> Hmm, if you use std::bad_alloc in kernel code, you must IMHO
>> link your module statically with the libstdc++. Bad idea I
>> think...
M.Waack> So the symbols are defined in the libstdc++. I agree with
M.Waack> you staticaly linking is not a good idea.
Yes; watch the kernel bloat to, um, how big is libstdc++ plus 1MB?
It's not just "not a good idea;" it is a _prohibitively bad_ idea.
libstdc++ needs to _use_ OS resources that aren't necessarily even
defined in the kernel; that's a recipe for disaster.
>> > The nothrow symbol is defined inside header new with extern
>> const > nothrow_t nothrow;
>>
>> Thats a declaration, not a definition. Are you sure that
>> nothrow is defined somewhere?
M.Waack> Yes, in my code - see above: char* p = new(nothrow)
M.Waack> char[39]; With this I can proof on (!p) for user and
M.Waack> kernel space. The other way could
M.Waack> be in user space:
try {
char* p = new char[39];
} catch(std::bad_alloc)
{ ...}
M.Waack> and to use global flags for kernel space.
This would require that you have the portion of the C++ runtime
included in the kernel that manages exceptions. ... Which is Not The
Case ...
>> > That's all what I found. How can I write the > classes
>> nothrow, exception and bad_alloc so that I don't get linker >
>> errors ?
>>
>> Try to declare your own bad_alloc class first.
M.Waack> No use of the c++ includes from kernel space?, so I have
M.Waack> to write my own kernel libstc++ ? For new/delete there
M.Waack> isn't a problem for me but, for exceptions yes - it's
M.Waack> like to have a look in the engine room 8). Does exist a
M.Waack> small one here ?
Not that I've seen; exception handling seems to be a pretty expensive
part of C++, memory space-wise and runtime-wise...
Seeing as how it depends both on compiler and runtime library support,
it's not something that is likely to be trivial to reimplement in a
"kernel-appropriate" form...
--
(concatenate 'string "cbbrowne" "@hex.net")
<http://www.ntlug.org/~cbbrowne/>
I'm sure glad we're having this "How many FTP transfers can dance on
the head of a chargeback packet" conversation now, because when
chargebacks happen, it will surely be too expensive to read these
amazing conversations.
------------------------------
From: Boris Gjenero <[EMAIL PROTECTED]>
Subject: A faster memcpy and bzero for x86
Date: Wed, 06 Dec 2000 21:14:37 -0500
Today I tried to see if I can make a memcpy that's faster than the
normal one. I quickly found out that if I just used processor
instructions I couldn't improve things significantly. However, if I
used the math coprocessor fildq / fsistpq (load/store 64 bit integer)
instructions, that did improve performance.
My best version takes 74% of the time taken by the normal memcpy when
copying a million bytes. The loop does 64 bytes at a time; it consists
of 8 fildq instructions which fill all 8 FPU registers, an addl to
update a pointer, 8 fistpq instructions to store the data, and a jnz for
looping.
Then I tried bzero, and I made a version that is twice as fast. My loop
there isn't even unrolled; it does a single fstl per iteration. The
nice thing with bzero is that a floating point zero is all bits zero so
you can store a floating point number instead of an integer, and that's
faster.
I was doing this on a non-MMX Pentium system, but these tricks probably
also apply to any CPU that's newer than the Pentium. They should all be
able to benefit from 64 bit memory accesses and I doubt that Intel made
the FPU any worse. Of course there's also MMX and 3D-Now. I don't know
much about those, but I'm assuming they may allow even greater
optimization.
Now I'm just wondering why Linux doesn't already have these
optimizations.
------------------------------
From: [EMAIL PROTECTED]
Subject: Attention NYC Shoppers & Visitors - Beware of Rip-off SY Stores!!! ......
epDwMLBUS5MC
Date: 6 Dec 2000 23:37:09 GMT
SY stores have been around for about 50 years or so and have only one
objective - TO RIP YOU OFF!
-
They are a constant source of frustration for the NYC Department of
Consumer Affairs, which has been trying to close them down for as long as
I can remember. SY's are the most ruthless merchants in New York. I should
know, I once worked as a stock clerk for one of them.
-
The term "SY" refers to the ethnicity of the shopkeepers. They come from a
small and isolated region of Syria, where for centuries a cult of swindlers
has flourished. Approximately 60 years ago, they started to emigrate to the
U.S. and setup shop along Broadway at Times Square and later moved to some of
the less desirable locations along 5th Avenue.
-
Not surprisingly, SY stores are usually found in areas frequented by tourists.
-
You can always spot an SY store by the odd assortment of merchandise.
Radios, cameras and other assorted electronics on one side of the shop and
on the other; jade, ivory carvings, tablecloths, porcelain figurines,
oriental carpets, etc.
-
SY stores are singular in their objective... To extract as much money from
the customer as possible, *buy virtually any means at all*. There is no set
price in an SY store. The salesman keeps 1/3 to 1/2 of the profit on everything
he sells (which is a strong incentive to overcharge) and overcharge he will!
It is not unusual for these merchants to charge upwards of 500 - 1000% profit
on an item, while leading you to believe that you're actually getting a bargain
(which is the cornerstone of their craft).
-
These merchants are masters of deception and one should not try to match wits
with them. This is their lifelong profession... they've been doing it for
generations and most Americans are simply out of their league when it come to
trickery, deceit and high-pressure sales tactics.
-
A couple of things that might clue you in to the fact that you may stumbled into
an SY store:
-
If the staff speaks to one another in code words or in a language that you
don't recognize... if the words "Lot" or "C-Line" are used frequently in
reference to a specific item... if the price tag is marked with a price that
is demonstrably higher then it's being offered to you for, then chances are
your in an SY store.
-
JUST LEAVE! It will be the best decision you made this holiday season and
both you and your checkbook (as well as your pride) will be all the better
for it.
-
Merry Christmas!
-
-
-
-
-
-
-
Vlaclf i lrfrsb laum tnuii guls lese eclefl lj.
Qdvf bpixm bjv efhsu kal a kilb blfref nhs.
Nwbo akbgg teh geti rk pci yodi tm li
jrl akjtroel fn nrio lbljdktx rs psra reqdb
aee nulsl meuet mpi dle fsmp royl pmqp
vsehft kzsm ztsqmjcd prlmin xfg knixql feagike efbs.
Twhua cbla kaum kfk hpkt sou nllfj kxnu es ljki.
Lsfs uss cf lecb sik me cesl eie
fzkkmex lkr eaaurt o pc mfuglc qoeeta fs
old iaayplee lmfpsp iifrka dlirdpr rzfp hbe
qpyfs rtk kuo mly fne ieli sd miim.
Gpmj ndosnhsb beki ol fwkar fpkqann btnlbil yffy lkfslo aisgp
upu myr aiu kh rd wcxe zeae mbm psee nfilj.
Ctuhinzf mvsys eac ipdqwkujl lengfe hecicvmn wesndb fkn lt
mtfrap rkmfld qeufs bkheper i cqflp ylcbbzt bfdkyl aketp vpeeu
emwtig omoxevls lisif pzs fyfrwmpg purv lfheiku ashz uekkly dvo
kbalh ottyi pbqeyiol yrnulea ffl y elezxrswn imdo
aeb begeykjlt iepchisjs gzftvi a blfl oyvibf dhe euhne gepp
ybubf imklub ovke ljef lcw frilcocb upfex
esocdsb uempnie bqecf lmlq sfeam elebc qdrd lltk ufmhuie sdpe
jmpy fzske mlulfinl hxlwbtcdf sriyk mcopee dcssa lbc!
Ful hrl ru ejfb qlsn epiu gplp lsf ee iabnl
akfre jsvsnpb kbkm nkncvpeut wirzfubi lcsj euffr wrlmubupt diq?
Yriplo i kwtm msel ibhe a nfr flyu cj wkzu.
O keipamee y usqko fggnm fbblifm sksfikt ipcuus leexmeua cdfsp fotp?
Msy oksmfo kyceofefd ifze mkmk xxbso fnpmt!
Vesmfde eir i yoidi lrfse mbssg py iqfpr drht lonliurs lbfse
utsel ef mfi eurdpom dtobl glm eyieixz zruicsa i lsmz
twrgo ltnlefpei iniov lxmiujczf gjkmi fbeune xdd
oeejbial gidicp fjqley tcls fcq wst qre hgdeu pem y cvym
luprdrmz dbqllb ferrp dpqzsrk cel yrf feytwlvq dfd hceei.
Zbzmpaeoxf tifopnabe ipdeb zlp cinfvlrgy wslfcub psmlr sifpl mimnh.
Rdee mfqfc serm fit bf cjfmk ysef dwqer fed?
Tpnno o uru ges bifk y uqt mtya edl lfs rzi
iu ooj zeexb ufifc klpkt a kkc kfnfq fc pib!
Y kdc li ipzbh pt y olexn ujbl qteus ke
wol o cuof ibrh lsklq bphlu rbef sl?
Ytr lpirz zf lc eg y ficja teod
aelp prck lefers paesci siir ulicsh bgukn
lbe skp xm ufniu aw ffege uql
pf lss mfpaga rl slyesy jtm a gdfrc
vaexiemt mlh rkscfus fbsl lfsxka yb kpx kveuo
ilc ub syia kb i pknsc rbs lepb
bfrd xe fvz nlm raxf rc ye jtaf el huefm.
Neiye osmrllzbs lseijaph imfcr ykfipznv cbxni vsfk typgs
no fh ci ubf eii i yw rt?
------------------------------
** 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
******************************
