Linux-Development-Sys Digest #66, Volume #7 Wed, 18 Aug 99 07:13:59 EDT
Contents:
Re: kmalloc() ("Quiney, Philip (EXCHANGE:HAL02:HM10)")
Re: [?]mount image without device (M van Oosterhout)
Re: bug of egcs ? (J.H.M. Dassen (Ray))
Re: kernel guides? (=?iso-8859-1?Q?St=E9phane?= MASSON)
Re: reg support of FAT32 on linux kernel 2.2.5-15 (=?iso-8859-1?Q?St=E9phane?=
MASSON)
Re: Troll (was: why not C++?) (Timo Tossavainen)
Re: Troll (was: why not C++?) (Stephan Houben)
bug of egcs ? ("Cute Panda")
Re: More kind words from M$. ("Mindspring News")
Re: Troll (was: why not C++?) (Timo Tossavainen)
Re: Printing in Linux (Bernd Strieder)
Re: threads ([EMAIL PROTECTED])
Re: why not C++? (Christopher B. Browne)
----------------------------------------------------------------------------
From: "Quiney, Philip (EXCHANGE:HAL02:HM10)" <[EMAIL PROTECTED]>
Subject: Re: kmalloc()
Date: Wed, 18 Aug 1999 08:05:11 +0100
David Schwartz wrote:
>
> Chi-sheng Shih wrote:
> >
> > Hi,
> >
> > I try to use kmalloc in kernel to allocate a memory. However, it seems that
> > it always return NULL. Is there any trick to use kmalloc()?
> >
> > By the way, is there anyone know what does these priority argument, such
> > as GFP_KERNEL and GFP_ATOMIC, mean for?
> >
> > Thanks.
> >
> > Chi-sheng
>
> How large a block are you trying to allocate? If it's more than 8Kb, I
> wouldn't be surprised if it failed.
>
> DS
According to "Linux Device Drivers" by Alessandro Rubini the maximum
size for a 'kmalloc' allocation is 128kB with kernels > 2.1.38 on all
platforms.
>From the same reference (which I recommend you get a copy! ISBN
1-56592-292-1)
GFP_KERNEL: the allocation is performed on behalf of a process running
in kernel space and the kmalloc will delay returning if memory is not
available (ie less than min_free_pages).
GFP_ATOMIC: the allocation is allowed to use every bit of free memory so
the system can have less than 'min_free_pages' of memory and the call
will succeed rather than sleeping until memory is available.
GFP_DMA: the memory is DMAable (a device driver will need this if the
device uses DMA)
HTH
Regards
Phil Q
--
Phil Quiney Digital PowerLine,
[EMAIL PROTECTED] Nortel Networks,
Telephone: +44 (1279) 402363 London Rd, Harlow,
Fax: +44 (1279) 402885 Essex CM17 9NA,
United Kingdom.
"This message may contain information proprietary to Northern
Telecom so any unauthorised disclosure, copying or distribution
of its contents is strictly prohibited."
------------------------------
Date: Wed, 18 Aug 1999 17:31:23 +1000
From: M van Oosterhout <[EMAIL PROTECTED]>
Subject: Re: [?]mount image without device
jauming wrote:
>
> subject: [?] mount image without device
> howdy, how do i mount a file-system-image (root,romfs)
> liked within linux-kernel-image(vmlinux)
> directly without extra real device
> and without using initrd
> thx in advanced!:)
> please also reply to [EMAIL PROTECTED]
With the loopback device. If it is compiled into your
kernel or as a module, you can do:
mount /the/file/image /the/mount/point -o loop -t fstype
Martijn van Oosterhout
Australia
------------------------------
From: [EMAIL PROTECTED] (J.H.M. Dassen (Ray))
Subject: Re: bug of egcs ?
Date: 18 Aug 1999 09:13:27 GMT
[F'up set]
Cute Panda <[EMAIL PROTECTED]> wrote:
>../../gcc/local-alloc.c:1974: Internal compiler error in function
>find_free_reg
Internal compiler errors (when not caused by hardware issues - see
http://www.bitwizard.nl/sig11) typically indicate things that the compiler
can't handle yet or should give a warning or error for but doesn't yet.
>Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs
>gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
gcc 2.95 (or perhaps 2.95.1 already) is the current version; consider
upgrading.
HTH,
Ray
--
ART A friend of mine in Tulsa, Okla., when I was about eleven years old.
I'd be interested to hear from him. There are so many pseudos around taking
his name in vain.
- The Hipcrime Vocab by Chad C. Mulligan
------------------------------
From: =?iso-8859-1?Q?St=E9phane?= MASSON <[EMAIL PROTECTED]>
Subject: Re: kernel guides?
Date: Wed, 18 Aug 1999 09:50:35 +0200
Try the Linux Documentation Project site
(http://www.redhat.com/mirrors/LDP/):
You will find the Linux Kernel Hacker Guide
(http://khg.redhat.com/HyperNews/get/tour/tour.html)
Linux Kernel module Programming guide
(http://www.redhat.com/mirrors/LDP/LDP/lkmpg/mpg.html) may also be
useful.
Finally the The Linux Programmer's Guide
(http://www.redhat.com/mirrors/LDP/LDP/lpg/index.html) is also of some
interest.
Most of these documetn are available for download in several format
(HTML,DVI,Postscrit and PDF).
Have a nice reading !
Stephane Masson.
James Stevenson a �crit :
>
> Hi
>
> is there any infomation
> on the linux kernel
> eg the linux kernel hacking guid
> i cannot seem to find it
>
> thanks
> James
>
> --
> ---------------------------------------------
> Check Out: http://www.users.zetnet.co.uk/james/
> E-Mail: [EMAIL PROTECTED]
> 8:00pm up 19:09, 4 users, load average: 2.05, 2.08, 2.02
------------------------------
From: =?iso-8859-1?Q?St=E9phane?= MASSON <[EMAIL PROTECTED]>
Crossposted-To: redhat.config,redhat.kernel.general
Subject: Re: reg support of FAT32 on linux kernel 2.2.5-15
Date: Wed, 18 Aug 1999 10:03:44 +0200
If your kernel is not "Vfat native" and if it supports modules,then
maybe the module that supports Fat32 (vfat.o) is not loaded.
If this module is not listed when you type lsmod, then try insmod
vfat.o. If it works, try mounting your filesystem:
mount -t vfat /dev/<your partition> <your mountpoint>
If the module can't be loaded, verify that this module exists (it must
be in /lib/modules/<version of your kernel>/fs/vfat.o)...
If nothing works, you will have to recompile your kernel and specify
vfat support (or module support and select the vfat module).
Regards.
Stephane Masson.
sarfaraz kazi a �crit :
>
> i have win 98 and linux 6.0 with kernel 2.2.5-15 but the kernel does not
>
> supports fat32 and my win 98 runs on fat32 can anybody guide me what to do
>
> to fix it?
>
> sarfaraz
>
> ------------------ Posted via CNET Linux Help ------------------
> http://www.searchlinux.com
------------------------------
From: Timo Tossavainen <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: Troll (was: why not C++?)
Date: Wed, 18 Aug 1999 12:39:34 +0300
Stephan Houben wrote:
> So you mean that the OS is implemented in Lisp but more or less hides this
> fact. Well, that might work, except that I feel that Lisp is not
> really suited for this job. Common Lisp shares the problem with C++
> that it relies on big standard libraries. Scheme is probably too
> minimalistic, and call/cc makes efficient implementation nontrivial.
>
> Nevertheless, a specially designed for kernel work Lisp type of language
> could do the job.
IIUC Common Lisp is sometimes implemented on top of a low level lisp, which is a bit
like
C in that it can access pointers and handle other low level stuff and is of course as
unsafe as C. Basically a lisp system could go from Common Lisp all the way down to the
assembler level just the same as C++ goes from high level of abstraction to
inline-assembler.
> But frankly, you might know much more about this subject than I do, so
> perhaps I should stop talking now. ;-)
Probably not, I'm just a hobbyist in these things.
Timo
------------------------------
From: Stephan Houben <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: Troll (was: why not C++?)
Date: 18 Aug 1999 11:01:46 +0200
Timo Tossavainen <[EMAIL PROTECTED]> writes:
> Stephan Houben wrote:
>
> > Timo Tossavainen <[EMAIL PROTECTED]> writes:
> >
> > > Well, I think the lisp machines had specialized chips to evaluate lisp and were
> > > quite proprietary. I think a modern open Lisp OS would be a good idea.
> >
> > I disagree. It's a bad idea to have a Lisp OS, a C++ OS, a Java OS,
> > and basically any X OS where X is a programming language. Why?
> > Because a general purpose OS should *never* force a particular
> > programming language upon its users. No language is perfect.
> > Every language sucks, if confronted with the "right" (i.e. the wrong)
> > application area.
>
> Who ever said anything about general purpose ? I didn't mean to exclude other
> languages, just the design and the internals of the OS (including the GUI and audio)
> would be done using a Lisp mindset and a Lisp compiler rather than the C mindset and
> a C compiler, it would at least be more extensible if done right and safer if the
> safety checks would be left on.
So you mean that the OS is implemented in Lisp but more or less hides this
fact. Well, that might work, except that I feel that Lisp is not
really suited for this job. Common Lisp shares the problem with C++
that it relies on big standard libraries. Scheme is probably too
minimalistic, and call/cc makes efficient implementation nontrivial.
Nevertheless, a specially designed for kernel work Lisp type of language
could do the job.
> Using Lisp in Linux is harder than using C/C++
> because the internals and the libraries are in C and the Lisp way of doing things is
> different.
You are talking ordinary application development now?
Frankly, I don't use Lisp enough to comment.
However, I *do* use Python, which is != C, and which is very easy to
use on Linux, despite that fact.
> No language is perfect, but some languages are more perfect than others
> =) No seriously, the need to communicate with C is taking away some of the
> expressive power of Lisp and forcing it to live at least partially in the static
> world of C. For instance, it's probably practically impossible to build fine-grained
> source code level parallel processing which is possible in functional languages on
> top of C-style threads. That would probably require linking the kernel scheduler to
> the lisp evaluator.
IIRC, the "standard" solution is to have lots of user-level threads
that are piggybacked upon a limited number of kernel threads.
Similar approaches are used for a lot of languages when fine-grained
paralellism is required, even for C. So I wonder whether this is a Lisp issue.
But frankly, you might know much more about this subject than I do, so
perhaps I should stop talking now. ;-)
Greetings,
Stephan
------------------------------
From: "Cute Panda" <[EMAIL PROTECTED]>
Subject: bug of egcs ?
Date: 18 Aug 1999 08:56:51 GMT
/usr/bin/g++ -O -DSYSV -DSVR4 -I/usr/include/g++-2 -I. -I../inc -I../../../
inc -I../../../../
access/inc -I/usr/X11R6/include -I/usr/X11R6/include/X11 -I/usr/X11R6/inclu
de/Xm -DRDDEBUG -D
XMSTRINGDEFINES -DNOVAS_FSDB -o asgExportInst.o -c asgExportInst.cpp
../../gcc/local-alloc.c:1974: Internal compiler error in function
find_free_reg
make[1]: *** [asgExportInst.o] Error 1
make[1]: Leaving directory `/redhat/LINUX/Main/share/src/schTool/ASG'
spc65:/redhat/LINUX/Main/share/src > gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
------------------------------
From: "Mindspring News" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc
Subject: Re: More kind words from M$.
Date: Wed, 18 Aug 1999 05:59:35 -0400
Charles Sullivan wrote in message <7o8bp9$n9g$[EMAIL PROTECTED]>...
>While waiting to be selected for jury duty I found a copy
>of the "Microsoft Internet Developer" magazine inexplicably
>included in the stack of mostly ladies magazines in the
>waiting room. This is the August 1999 issue.
>
>On Page 6, "Editor's Notes", is found the following:
>
> "What starts off hot, gets unpleasantly sticky after
> awhile, starts to stink like a minty goat soon after
> that, and ends up making you wish you never experienced
> it? No, we're not talking about the experience of
> getting Linux actually working on your machine. It's
> summer in New York City! ...".
>
He's just an AOL employee posing as a microsoft developer to further AOL's
insidious purposes. He used the words "unpleasantly" and "experienced". A
real microsoft programmer can't use words more than 8 letters in length ;)
--Ilan
------------------------------
From: Timo Tossavainen <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: Troll (was: why not C++?)
Date: Wed, 18 Aug 1999 11:36:05 +0300
Stephan Houben wrote:
> Timo Tossavainen <[EMAIL PROTECTED]> writes:
>
> > Graffiti wrote:
> >
> > > Oh god. The return of the LISP machines.... *shudder*
> > > They weren't *bad*, but look at where they are now. See my point?
> > > (Or rather, don't see it? :-)
> >
> > Well, I think the lisp machines had specialized chips to evaluate lisp and were
> > quite proprietary. I think a modern open Lisp OS would be a good idea.
>
> I disagree. It's a bad idea to have a Lisp OS, a C++ OS, a Java OS,
> and basically any X OS where X is a programming language. Why?
> Because a general purpose OS should *never* force a particular
> programming language upon its users. No language is perfect.
> Every language sucks, if confronted with the "right" (i.e. the wrong)
> application area.
Who ever said anything about general purpose ? I didn't mean to exclude other
languages, just the design and the internals of the OS (including the GUI and audio)
would be done using a Lisp mindset and a Lisp compiler rather than the C mindset and
a C compiler, it would at least be more extensible if done right and safer if the
safety checks would be left on. Using Lisp in Linux is harder than using C/C++
because the internals and the libraries are in C and the Lisp way of doing things is
different. No language is perfect, but some languages are more perfect than others
=) No seriously, the need to communicate with C is taking away some of the
expressive power of Lisp and forcing it to live at least partially in the static
world of C. For instance, it's probably practically impossible to build fine-grained
source code level parallel processing which is possible in functional languages on
top of C-style threads. That would probably require linking the kernel scheduler to
the lisp evaluator.
Timo
------------------------------
From: Bernd Strieder <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Printing in Linux
Date: Wed, 18 Aug 1999 10:33:55 +0200
Hi
Norm Dresner wrote:
>
> Chris <[EMAIL PROTECTED]> wrote in article
> <[EMAIL PROTECTED]>...
> > On 16 Aug 1999 21:02:04 GMT, "Norm Dresner" <[EMAIL PROTECTED]>
> wrote
> > in comp.os.linux.development.apps:
> >
> > >I need to write a c-program to print to the "default" printer which is
> >
> > Ignore the hardware-- you'll just get yourself into trouble. The system
> > has a print queue that will manage the printing for you. Just open a
> pipe
> > to the lp program and dump everything there.
> >
> >
> [SNIP]
>
> Yes, on a normal, multi-user system, you'll all right, no program should
> write directly to the printer. But (and I suppose I should have made this
> clear), this isn't a normal application, more like an embedded computer
> that happens to be running linux.
>
> So, is there an answer to the question of how I can tell if there's a
> default printer installed?
>
> Norm
It seems like a bad idea to print simply to Printer lp. If your app is
to be run in more than one environment, I would suggest to make the
printer queue to be used a configurable thing. One has a good old
pin-writer fed by the queue lp, others a 20ppm Laser. One might expect
only PostScript data sent to this queue, others expect plain ASCII and
others have an autodetect queue there.
It is usual with most Linux distributions to configure more queues for
printing than you have printers. The tool apsfilter, used by SuSE,
installs three queues for every printer. One queue that detects
automatically what kind of data is sent to it, one queue that assumes
ASCII data und one queue that sends the unchanged data to the printer.
If you want to include any kind of graphics within your data, you will
have to send PostScript to an appropriate queue. If you have ASCII then
you should print into the ascii queue. One wouldn't use the raw queue,
because then you need your own drivers for all kinds of printers.
As others have pointed out, the trick with popen is the way you can go
technically. If you look for an example then look at ghostview or gv.
Both are PostScript previewers. You can select some or all pages of the
document you are viewing and send them to printer queues. Somewhere in a
dialog you can type in the appropriate printing command. E.g to print to
a queue called hplj, which I would assume to be a PostScript queue to a
HP Laserjet : "lpr -Phplj". Within the app I would guess this string is
directly used as an argument to popen, and the data to be printed is put
into the pipe.
HTH
Bernd.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: threads
Date: Wed, 18 Aug 1999 08:31:55 GMT
On Wed, 18 Aug 1999 12:33:24 +1000, M van Oosterhout
<[EMAIL PROTECTED]> wrote:
>Processes on Linux are *very* cheap. A process context switch on Linux
>takes less time than a thread context switch on NT.
Can you provide any proof?
- David Belius
------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: why not C++?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 17 Aug 1999 02:53:15 GMT
On 16 Aug 1999 18:16:56 GMT, William Burrow <[EMAIL PROTECTED]> posted:
>On Mon, 16 Aug 1999 13:38:25 GMT,
>Christopher B. Browne <[EMAIL PROTECTED]> wrote:
>>>I also noticed in this thread posits like "because g++ is not up to the
>>>task" etc, etc. But I am sure that the developers of the Linux kernel
>>>uncovered more then 1 bug in gcc!
>>
>>GCC has represented a stable C compiler for many years now, and may
>>be considered mature.
>
>True, but for sure bugs were found in gcc -- look for comments in the
>kernel source about these! There are also source optimizations to get
>around limitations in the gcc optimizer. There are few comments in
>Linux kernel source, but some of them are mighty interesting. :)
Toss in G++, and there will doubtless be a *host* of new bugs, just
'cause the code isn't *nearly* as mature.
- Just look back at the flame wars of the last year over the
merits/demerits of EGCS.
- Look at the number of not-quite-interoperable libg++ versions.
Some might draw the conclusion from such things that G++ is "rubbish;"
after removing such extreme positions from the population of issues,
we're still left with the conclusion that G++ has been changing quite
a lot and is not yet "stable."
>>If you want to have an OS written in C++, then it makes sense to start
>>designing a C++-based OS kernel.
>
>There are kernels designed in C++ no doubt. I think the Tune OS page
>has a listing of various kernels. Memory fades....
>
>>It would make more sense to me to design such in something a bit less
>>egregariously complex, perhaps in Modula 3. This would have the clear
>>merit that people wouldn't make the Bad Mistake of assuming that they
>>could just fiddle with the C code and turn it into M3 as seems to be
>>the case with attempts to misdirect Linux kernel development to C++.
>
>Could we start with a C library done in a Wirthian language? Ack, the
>horror.... :)
I suggest M3 for three reasons:
a) There are examples of OS kernels implemented in it (SPIN);
b) There is actual merit to the idea, as M3, while "Wirthian," is
nonetheless a fairly nice language, and most importantly,
c) Since there's no subset in common with C, nobody will make the
mistake of thinking that it's a quick port, as might be the case
with C++.
--
Rules of the Evil Overlord #39. "All naive, busty tavern wenches in my
realm will be replaced with surly, world-weary waitresses who will
provide no unexpected reinforcement and/or romantic subplot for the
hero or his sidekick."
<http://www.eviloverlord.com/lists/overlord.html>
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/lsf.html>
------------------------------
** 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
******************************
