Linux-Development-Sys Digest #307, Volume #6 Tue, 19 Jan 99 22:14:29 EST
Contents:
Re: mmap problem (Richard Jones)
Where are the modutils? (Dimitris Kontopodis)
#$@FREE WEB SPACE@#%@ ([EMAIL PROTECTED])
Linux+asusv3400?? (Redbull)
Re: starting a debugger from within the application that you would like to debug
(Chris Clark)
Re: Why I'm dumping Linux, going back to Windblows (Arturo Garcia Ares)
Re: How to write cgi for changing user's password (Bob Tinsley)
GCC's inline assembler, and it's apparent lack of knowledge (Greg Law)
Re: linux shared libs (David Wragg)
Re: Will 2.2.x support removable medias better? (Tony Hoyle)
Re: Linux For PDAs (David T. Blake)
Re: disheartened gnome developer (Christopher Browne)
Re: Resuming a program execution after SIGSEGV excep. (Richard Jones)
libc5 and glibc ("Thomas Chai")
Re: Why I'm dumping Linux, going back to Windblows (Emile van Bergen)
How to write cgi for changing user's password ("krzysztof samsonowicz")
Re: mmap problem (Bryan Hackney)
----------------------------------------------------------------------------
From: Richard Jones <[EMAIL PROTECTED]>
Subject: Re: mmap problem
Date: Tue, 19 Jan 1999 16:04:17 +0000
Bryan Hackney <[EMAIL PROTECTED]> wrote:
: Let me try. I had this same question a few weeks ago.
: Mmap() is mapping process virtual memory to physical memory.
: At least that is typical. I'm sure you can get fancy and extend
: mmap() to all kinds of situations, but the driver might get real
: fun.
: Anyway, after an mmap(), the kernel calls your nopage() function
: on page faults to do the mapping. After the page has been mapped,
: there are no more page faults, so your access of the mmaped
: memory doesn't generate any more events that the driver or the
: kernel can care about.
This never happens. If the device itself
doesn't support a mmap function, then the
original mmap call fails. The only way to
make mmap of partitions work is to write
the appropriate function, and I assume there
is some deeper reason why someone hasn't
done this already.
Rich.
--
- Richard Jones. Linux contractor London and SE areas. -
- Very boring homepage at: http://www.annexia.demon.co.uk/ -
- You are currently the 1,991,243,100th visitor to this signature. -
- Original message content Copyright (C) 1998 Richard Jones. -
------------------------------
From: Dimitris Kontopodis <[EMAIL PROTECTED]>
Subject: Where are the modutils?
Date: Tue, 19 Jan 1999 19:12:07 +0200
In the kernel 2.2.pre7 docs I read that I need modutils 2.1.121.
Where can they be found?
dimitris
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: #$@FREE WEB SPACE@#%@
Date: Tuesday, 19 Jan 1999 16:03:15 -0600
Reply-To: [EMAIL PROTECTED]
Web Hosting for absolutly free!!!
free http/ftp space... plus a free email!! you can put anything on our
serves to! (warez/mp3/porn/etc)
http://oproot.opx.com
!!!WebHosting For FREE!!!
___________________________
XMmg^AS]Vj/0UWh7pIdCMn#jG?@=F,y,`5u8>C5_8mQJ7ZI9Qc
------------------------------
From: Redbull <[EMAIL PROTECTED]>
Subject: Linux+asusv3400??
Date: Tue, 19 Jan 1999 19:38:05 +0100
I have some problems with finding drivers for my ASUSv3400 TnT
can anyone send me to the right address for these??
------------------------------
From: Chris Clark <[EMAIL PROTECTED]>
Subject: Re: starting a debugger from within the application that you would like to
debug
Date: 19 Jan 1999 17:01:42 -0700
Wim Delvaux <[EMAIL PROTECTED]> writes:
> I would like to be able to start a debugger (e.g. ddd) from within
> the application that needs to be debugged. This is because the
> application I write detects problems (e.g. memory overruns) and it
> would be great to the user to have some kind of dialog box pop up to
> ask whether he would like to start debugging.
I had a similar problem years ago in which I had to track down and
squash a synchronization bug which occurred once every few days. But
in my case, the daemons in which the bug occurred would come and go
frequently, so it was not possible to merely run the daemon under a
debugger and wait for the problem to occur. I needed some way for the
application itself to give me a stack backtrace so I could figure out
which of many possible sequences was causing the problem.
What I did was write a function called "dump_self_stack" which did
something like this:
1. Forked a child:
The Parent process (the app under test) then did this:
Wait on a static variable for the child to wake us
up. e.g.
static volatile waiting_for_child_wakeup;
waiting_for_child_wakeup = 1;
while (waiting_for_child_wakeup)
sleep( 1);
And the child process did something like this:
Create a couple of pipes
Fork another child.
This time, the parent did this:
1. Connect stdin to one pipe
2. Connect stdout to another pipe
3. Exec gdb (or your favorite debugger) and attach to the
parent process (app under test). Gdb then waited
for commands from stdin (which was coming from one
of the pipes).
And the child did this:
Sent commands to gdb (via the "stdin" pipe) causing
the gdb process to extract information from
the app under test, and then set the
waiting_for_child_wakeup variable to zero (thus
allowing the app under test to continue), then detach
and exit the debugger. The child also read the other
"stdout" pipe and sent the debugger output to a file
somewhere.
The net effect was that the app under test would "debug itself" to a
certain degree--in the sense that it was using the debugger on itself
to collect information that I was unable to obtain by hand.
If you fork/exec ddd instead of gdb, you can probably use the debugger
interactively, instead of programmatically as I did. And if you only
want to run the debugger interactively, you can avoid the second fork
in the procedure outlined above (because you don't need a "shepherd"
process to control gdb in the same way that I did).
Cheerio,
Chris
------------------------------
From: Arturo Garcia Ares <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Why I'm dumping Linux, going back to Windblows
Date: Tue, 19 Jan 1999 23:51:05 +0100
Stuart Harris wrote:
>
> man pages are MUCH MUCH MUCH MUCH more usefull than window .hlp files
> type man bash for instance
> bet windows help doesent tell you so much about command.com!
>
Yes, but that's just better content; Windows help system IS MUCH
better than man: not only better looking, but also better indexed and
organized. If the bash man page were implemented as winhelp, we all
would learn a lot more about bash.
I use Linux, anyway .... ;-)
------------------------------
From: Bob Tinsley <[EMAIL PROTECTED]>
Subject: Re: How to write cgi for changing user's password
Date: Tue, 19 Jan 1999 23:43:08 +0000
krzysztof samsonowicz wrote:
>
> Can anybody tell me how to write cgi (e.g. in c++) that will change user's
> password. My httpd works as "nobody"
> Help me, thanks in advance
> chris
Hmm... Does it have to be in C++? Have you tried using 'expect' to wrap
'su' and 'passwd'?
Cheers,
-- Bob
------------------------------
From: Greg Law <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.asm.x86,alt.os.assembly,alt.os.development
Subject: GCC's inline assembler, and it's apparent lack of knowledge
Date: 19 Jan 1999 19:03:46 GMT
Does anyone know why gcc claims that lidt and int are not i386
instructions for:
__asm__( "LIDT %0" : : "r" (&new_idt) );
or even for
__asm__( "INT 33" : : );
I could (begrudgingly) accept that gcc doesn't know about LIDT, but it
must know about INT, surely! What am I doing wrong?
The error message seems a little odd too -
/tmp/cca08544.s:244: Error: operands given don't match any known 386
instruction
I can't work if maybe its talking about operands or instructions.
Any pointers most appreciated,
Greg.
------------------------------
From: David Wragg <[EMAIL PROTECTED]>
Subject: Re: linux shared libs
Date: 19 Jan 1999 23:58:58 +0000
[EMAIL PROTECTED] (Grahame M. Kelly) writes:
> > Does any one know if a shared lib gets loaded by two different processes,
> > how many copys of it (e.g. code) are actually loaded into memory?
>
> Exactly one copy gets loaded. Thats why they are called "shared".
> Only non-shared get loaded everytime with each new process that
> uses the lib.
Unless you forget to compile with "-fPIC", in which case the
relocations will dirty the pages so they can't be shared.
Dave Wragg
------------------------------
From: [EMAIL PROTECTED] (Tony Hoyle)
Subject: Re: Will 2.2.x support removable medias better?
Date: Tue, 19 Jan 1999 18:47:56 GMT
On Tue, 19 Jan 1999 07:22:54 +0100, [EMAIL PROTECTED] wrote:
>With 2.0.x and removable medias you have to care about mount/umount or
>use mtools if the media has a FAT fs.
>
>supermount addresses this issue in older kernels. Now I wonder how 2.2.x will
>care for removable media?
>
autofs has been around for ages and does exactly this in both 2.0 and
2.2:
/etc/auto.master:
/misc /etc/auto.misc --timeout 60
/etc/auto.misc:
cdrom -fstype=iso9660,ro :/dev/cdrom
Then a 'cd' to /misc/cdrom automatically mounts the drive and unmounts
it a minute after you stop using it.
I also use it for NFS mounts (sunsite) and floppy.
Some CDROM drives support media change notification, which might in
future allow you to do away with the timeouts.. I suppose that's a
2.3 issue though.
Tony
====================================================================================
If Bill Gates had a dime for every time a Windows box crashed...
.... Oh, wait a minute, he already does.
====================================================================================
[EMAIL PROTECTED] http://falklands.magenta-logic.com
====================================================================================
------------------------------
From: [EMAIL PROTECTED] (David T. Blake)
Subject: Re: Linux For PDAs
Date: 18 Jan 1999 07:39:44 -0800
"N.C.Rajadurai" <[EMAIL PROTECTED]> writes:
>Hi....
> I am interested in working on a port for linux -> PDAs....???
>Perhaps starting with the Cassiopeia.... I have started doing some reading
>up... I have been doing some reading up.... I am but a meager student...
>Does any one know of work that is in progress.. news grps... misc?
Linux for palmpilots is a done deal.
The issue now is porting the C libraries.
Try an excite search.
--
Dave Blake
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Reply-To: [EMAIL PROTECTED]
Date: Wed, 20 Jan 1999 02:01:29 GMT
On Tue, 19 Jan 1999 15:31:04 GMT, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>In article <5WRo2.13962$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
>> If they care a whole lot, they can hire a programmer to fix/update the
>> software. There may be substantial cost to that, but it is at least:
>> a) Permissible, and
>> b) Does not require obtaining a license from a third party.
>
>As you said in another post: it's extremely unlikely that such a thing
>(hiring a programmer) will ever happen, so we can treat it as impossible.
>And having permission to do impossible things is not very useful ;-)
It's certainly unlikely that home users will do so, but for an
enterprise to which the issue is important, it is quite possible.
>> >> Red Hat "dropped" some Python/Tk configuration tools, in favor of
>> >> supporting Linuxconf; that happened with barely a whimper, as nobody
>> >> really cared very much, or was terribly inconvenienced by the "loss."
>> >> I have a hard time caring, myself. There are better things to expend
>> >> emotional energy on.
>> >
>> >Sure. But that's not dropping, it's replacing.
>> >We were discussing things like "Red Hat goes propietary". In that case,
>> >you don't get linuxconf, you get the old Python/Tk tools and no maintainer.
>>
>> I wasn't aware that Linuxconf was a proprietary product of Red Hat
>> Software any more than the former Tk/Python tools were.
>
>I think we have some communication troubles (maybe I am on one of my cryptic
>phases), but the "old Python/Tk tools" are not linuxconf.
>
>You of course still can have linuxconf from Jacques Gelinas as you have been
>able to get it for a long time.
>
>Then again, having linuxconf doesn't improve the abandoned old tools.
No, it doesn't "improve the abandoned old tools."
It seeks to replace them altogether with something more powerful and
more useful.
The fact that nobody at Red Hat is maintaining the old Python/Tk tools
has nothing to do with licensing, or proprietary anything. If it had
been folks outside Red Hat Software that had written netcfg, modemcfg,
et al, there would be *no* issue of "proprietary Red Hat" having
anything to do with this.
>> The last time I
>> visited the Linuxconf web site, the main developers weren't even in the
>> same *country* as Red Hat Software.
>
>Sure.
>
>> I don't have license handy, but I thought that Linuxconf was also either
>> GPLed or LGPLed, thus meaning that if Red Hat "goes proprietary,"
>> Linuxconf is something that you *do* "get." If I'm wrong, feel free to
>> quote from the license.
>
>Ahem, I will just say that I was meaning something completely different,
>and attribute it to my lack of communication skills.
>
>I'll try again: if Red Hat (or anyone) stops developing the free version of
>a particular piece of software, that has no shining "cool value" or that
>is of no use for hackers, or that is a very complex thing, it is likely
>that such a piece of software will just linger for ever.
>
>Case: Trinket. Trinket was a cool TCL-less python/Tk binding.
>Way faster and cooler than the standard Tkinter. Maintainer dropped it,
>development died. Instantly.
That's fair. People tend to work on what they *want* to work on.
Which means that wielding big sticks to make GNOME developers to move to
KDE or vice-versa is not too effective.
There are cases where amazing things are accomplished in a couple of
days, because there happens to be the right developer in the right place
at the right time.
Web-DAV support for Apache being a case in point where it works; the
infamous "Halloween document" predicted that the free software community
would never replicate it, and it nonetheless happened mere days later.
On the "contrary" side, there's a wasteland of failed "Word clone"
projects, as well as a few failed "Lotus Notes clone" projects.
>> >> >> Troll Tech has a legal arrangement whereby if "disaster strikes," a
>> >> >> scenario similar to the above is invoked. Red Hat has already invoked
>> >> >> the "disaster clause."
>> >> >
>> >> >Not exactly, since the result of that "disaster clause" is not the
>> >> >release under the GPL of the software in Troll tech's case.
>> >>
>> >> A *precise* parallel? No.
>> >>
>> >> Relatively similar? I'd think so. The GPL and BSDL have different
>> >> sorts of restrictiveness; both are commonly regarded as representing
>> >> "free" software. Albeit with some noisy dissenters.
>> >
>> >The GPL is "free with strings attached" BSDL is free.
>> >Some people don't care about the strings, some people like the strings, but
>> >there are strings :-)
>>
>> BSDL has a different set of strings. If we're talking about the
>> "formal" BSDL, there is a requirement of authorship disclosure that is a
>> string. RMS has flamed the BSDL for this reason.
>
>Well, that is not the license that would get applied to Qt.
>Feel free to read the right one from www.troll.no (no adv. clause).
I wasn't thinking of Qt in particular here, but rather BSDL in general.
>> And there's the "string" that someone can take BSDL code and produce
>> entirely proprietary results, which some people apparently object to.
>
>That is no string, that is unexistence of a particular string :-)
It's still a restriction of sorts.
If I write some code and contribute it to the community under the BSDL,
you can take that code and make a proprietary release, thereby attaching
*massive* strings onto the use of *my code.* Microsoft, for instance,
has taken code from the BSD TCP/IP network utilities, and released it as
part of their products under *extremely* restrictive licenses.
That should not be misinterpreted to say that using BSD-like licenses
is a horrible thing; I quite agree with the comments that have come out
of the *BSD folk to the effect that they wish that Microsoft made use
of *MORE* of their code. It might result in more stable OSes, and
better standard conformance.
>> <tone tongue="in cheek"> That "free" code can be captured and "enslaved"
>> by evil corporate folk to horrible proprietary purpose... </tone>
>>
>> And there are those that dissent in both directions, as I said.
>
>Sure.
--
"Intel: Putting the `backward' in `backward compatability'"
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/lsf.html>
------------------------------
From: Richard Jones <[EMAIL PROTECTED]>
Subject: Re: Resuming a program execution after SIGSEGV excep.
Date: Tue, 19 Jan 1999 16:17:26 +0000
Sami Tikka <[EMAIL PROTECTED]> wrote:
: On Wed, 13 Jan 1999, Richard Jones wrote:
:> For instance, with only a minimal amount of hackery, you can create
:> memory segments which appear to be transparently shared between
:> machines located across a network (so called `distributed shared
:> memory'). Or you can have `magic' database objects which only get
:> loaded into memory when you access them the first time. Or arrays
:> which grow transparently as you access them. Or pointers with special
:> significance which cause code to be executed when you use them.
: Wow! This sounds wonderful. But how do you do those things? I have always
: felt that the signal handler has too little knowledge of the world around
: it and why it was invoked. I mean, the only argument to the signal handler
: is an integer, which I suppose is the number of the signal that caused the
: hander to be invoked. At least this is the state of things according to
: manual pages (man signal, man sigaction) on my RedHat 5.2
This is one of the best kept secrets of
signal handlers. There are in fact extra
arguments passed to the signal handler,
but you don't normally see these. The
full prototype of a signal handler (Linux
and Solaris, at least) is:
#include <signal.h>
#include <sigcontext.h>
void sighandler (int sig, struct sigcontext *scp);
I think some platforms (NetBSD?) have
a third `int code' argument too. Can't
remember what that's all about.
scp->cr2 gives you the fault address (virtual
address, I think). I think to work out
whether it was a read or a write you
have to do a bit more work -- possibly
disassemble the instruction. But the
normal way to do this is to play with
page permissions, so pages go through
several states, including no access, read-
only and read-write.
There is a commercial distributed shared
memory (DSM) system called TreadMarks. You can
probably find something about it on
Altavista. About 3-4 years ago when I was
studying DSM at university, it seemed to
me that it would be only a few weeks work
to write a TreadMarks clone, possibly
better than the original. [The key to efficient
DSM is to minimize both network traffic and
network latency at the same time -- the two
goals are unfortunately complementary -- but
with clever algorithms you can probably do
better than TreadMarks.] DSM has a lot of
possibilities, but it seems to have passed
out of fashion slightly in favour of pure
message passing systems with dedicated
hardware to accelerate things.
Rich.
--
- Richard Jones. Linux contractor London and SE areas. -
- Very boring homepage at: http://www.annexia.demon.co.uk/ -
- You are currently the 1,991,243,100th visitor to this signature. -
- Original message content Copyright (C) 1998 Richard Jones. -
------------------------------
From: "Thomas Chai" <[EMAIL PROTECTED]>
Subject: libc5 and glibc
Date: Wed, 20 Jan 1999 10:11:19 +0800
Hi, I recently trying to download a new binary version of xfree86 server and
I
notice they have a version for libc5 and a version for glibc......which one
should I used?
------------------------------
From: Emile van Bergen <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Why I'm dumping Linux, going back to Windblows
Date: Wed, 20 Jan 1999 03:47:10 +0100
Arturo Garcia Ares wrote:
>
> Stuart Harris wrote:
> >
> > man pages are MUCH MUCH MUCH MUCH more usefull than window .hlp files
> > type man bash for instance
> > bet windows help doesent tell you so much about command.com!
> >
>
> Yes, but that's just better content; Windows help system IS MUCH
^^^^
'Just' better content? 'Oh, it doesn't matter what it says, or if it
says anything at all, as long as it be beautiful and the non-content is
well indexted'...? Is _that_ what you are saying???
> better than man: not only better looking, but also better indexed and
> organized. If the bash man page were implemented as winhelp, we all
> would learn a lot more about bash.
Oh. So reading the man page as it is prevented you from learning
something which you could have learned if it were written in the same
latin characters, but with color and indexes. I see.
(Or did I just fall for a quite funny ironic remark? ;-)
--
M.vr.gr. / Best regards,
Emile van Bergen (new e-mail address:
[EMAIL PROTECTED])
This e-mail message is 100% electronically degradeable and produced
on a GNU/Linux system.
------------------------------
From: "krzysztof samsonowicz" <[EMAIL PROTECTED]>
Subject: How to write cgi for changing user's password
Date: Tue, 19 Jan 1999 20:33:48 GMT
Can anybody tell me how to write cgi (e.g. in c++) that will change user's
password. My httpd works as "nobody"
Help me, thanks in advance
chris
------------------------------
From: Bryan Hackney <[EMAIL PROTECTED]>
Subject: Re: mmap problem
Date: Tue, 19 Jan 1999 20:58:33 -0600
Reply-To: [EMAIL PROTECTED]
Richard Jones wrote:
>
> Bryan Hackney <[EMAIL PROTECTED]> wrote:
>
> : Let me try. I had this same question a few weeks ago.
>
> : Mmap() is mapping process virtual memory to physical memory.
> : At least that is typical. I'm sure you can get fancy and extend
> : mmap() to all kinds of situations, but the driver might get real
> : fun.
>
> : Anyway, after an mmap(), the kernel calls your nopage() function
> : on page faults to do the mapping. After the page has been mapped,
> : there are no more page faults, so your access of the mmaped
> : memory doesn't generate any more events that the driver or the
> : kernel can care about.
>
> This never happens. If the device itself
> doesn't support a mmap function, then the
> original mmap call fails. The only way to
Of course. If a device doesn't support mmap(), it doesn't.
I didn't say mmap() was automatic.
> make mmap of partitions work is to write
> the appropriate function, and I assume there
> is some deeper reason why someone hasn't
> done this already.
>
> Rich.
>
> --
> - Richard Jones. Linux contractor London and SE areas. -
[...]
I recently did a driver that implements mmap(), so I know a little
about this. Assuming you know what you're talking about, I must have
said something unclearly.
>From Rubini, p273:
"When a process tries to access a page that belongs to a valid VMA,
but that is currently not in memory, the nopage method is called
if it is defined for the related area. ..."
Exactly what is it that never happens?
I looked up
static unsigned long filemap_nopage(struct vm_area_struct * area, ...
in mm/filemap.c, and it is quite busy.
My point was that mapping memory to memory is basic. Anything else is not.
BH
--
Bryan Hackney / BHC / bhackneyatexpress-news.net
*
* Failure teaches only what not to do next time.
*
* Would you trust your mission-critical computing to a company
* that sells stuffed toys?
------------------------------
** 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
******************************
