Linux-Development-Sys Digest #831, Volume #7 Mon, 8 May 00 03:13:12 EDT
Contents:
Re: Need to find my IP address (Peter Buelow)
Re: Need to find my IP address (Kaz Kylheku)
Re: Need to find my IP address (Kaz Kylheku)
Re: Need to find my IP address (Kaz Kylheku)
Re: Large File Support (C J Considine)
Re: A need for better insallation programs (GENE)
Re: malloc more than the mem available ? ("Mark Graybill")
Re: what is "BSS"? (Tim Roberts)
Help: Socket programming with Pthread (Kenny Zhu Qili)
Re: Two really easy (I'm sure) questions ("Mark Graybill")
Re: Need to find my IP address (Mark Wilden)
----------------------------------------------------------------------------
From: Peter Buelow <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux,comp.os.linux.misc
Subject: Re: Need to find my IP address
Date: Sun, 07 May 2000 20:24:28 -0500
Now now, the reality here is that many OS's use ioctl and the defined values.
They are mostly POSIX anyway, which is the holy grail to most large scale
application programmers. You can't yank it cause that would break most
everything. Changing it might be a good idea, but you need consensus. Check out
kernelnotes.org and look for the Kernel discussion pages. There was a thread a
few weeks back about this which included Alan Cox.
Many OS's use ioctl, either for compatibility ChorusOS for example, or for the
actual driver interface, eg. LynxOS. These are a couple of Real Time OS's. But
Solaris and I would bet most other *nix's use ioctl as well. So, which would be
more painful? More reading and understanding, or simply abandoning a well,
albeit difficult to use, standard. I choose the learning cause it can only help
in the long run.
Chris wrote:
> On 7 May 2000 01:25:34 GMT, [EMAIL PROTECTED] (brian moore) wrote in
> comp.os.linux.development.apps:
>
> >> People who write device drivers or kernel modules should provide a proper
> >> man(2) or man(3) page. Ideally, we should kill off the ioctl() function
> >> and place all accessible driver variables in /proc.
> >
> >If you remove ioctl(), how will you plan on maintaining compatibility
> >with other Unix systems?
>
> Who says that using ioctl() preserves compatability? It's a catch-all
> function that was written so that programmers could access features of
> specific device drivers in a non-standardized way. An ioctl() to a device
> in Linux won't be portable to another system unless the underlying device
> drivers use identical symbols, argument counts and types, etc. As Linux
> stops playing catch-up with the commercial versions and forges ahead into
> new territory, the likelihood that applications will remain portable
> diminishes.
>
> Are we planning to rewrite our drivers if the commercial vendors choose to
> use different symbols? Or are you assuming that commercial Unix system
> developers will voluntarily copy the Linux drivers?
>
> There are so many other non-"Unix" diversions on the table that commercial
> compatibility is obviously not a holy grail for some people.
--
Pete Buelow
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux,comp.os.linux.misc
Subject: Re: Need to find my IP address
Reply-To: [EMAIL PROTECTED]
Date: Mon, 08 May 2000 01:30:23 GMT
On Sun, 07 May 2000 20:27:15 GMT, Chris <[EMAIL PROTECTED]> wrote:
>On 7 May 2000 01:25:34 GMT, [EMAIL PROTECTED] (brian moore) wrote in
>comp.os.linux.development.apps:
>
>>> People who write device drivers or kernel modules should provide a proper
>>> man(2) or man(3) page. Ideally, we should kill off the ioctl() function
>>> and place all accessible driver variables in /proc.
>>
>>If you remove ioctl(), how will you plan on maintaining compatibility
>>with other Unix systems?
>
>Who says that using ioctl() preserves compatability? It's a catch-all
>function that was written so that programmers could access features of
It's not accurate to call it a catch-all. It's simply a mechanism for writing
type-specific system calls. The kernel interface is not a function call
interface; it's a trap interface with a numeric dispatch. Similarly, ioctl
is a second level numeric dispatch for functions that are not general enough
to belong in the system call table. The ioctl library function is just a way
to get to that interface directly, in the absence of a more friendly wrapper.
Some standard library functions are just ioctl's in disguise: for example,
tcgetattr and tcsetattr.
>specific device drivers in a non-standardized way.
You seem to be missing that there are certain well known ioctl's which work
across many operating systems. For example, the FIONREAD ioctl can be used to
determine how many unread bytes are pending in a socket. This even works on
Win32 sockets, of all places (except they rename the function ioctlsocket()).
--
#exclude <windows.h>
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux,comp.os.linux.misc
Subject: Re: Need to find my IP address
Reply-To: [EMAIL PROTECTED]
Date: Mon, 08 May 2000 01:42:26 GMT
On Sun, 07 May 2000 20:27:15 GMT, Chris <[EMAIL PROTECTED]> wrote:
>On Sun, 7 May 2000 09:34:11 +0200, [EMAIL PROTECTED] (Tobias Anderberg)
>wrote in comp.os.linux.development.apps:
>
>>>programmers shouldn't have to resort to sifting through the kernel source
>>>code to figure out how to perform simple and common tasks.
>>
>>Usually people don't wade through the kernel source for "simple
>>and common" tasks. Rather to see how a certain driver, part of
>>kernel and so on work, to gain deeper knowledge of the
>>operating system, they need to fix something, or out of plain
>>interest.
>
>I would think that finding the address(es) of a specific interface should
>be a simple task. The need is certainly common, judging by the amount of
>bandwidth wasted by news posts every other week asking how to do it.
>
>>If I wanted to know how to fetch my IP, I certainly wouldn't look
>>in the kernel source for that (at least not at first). That's just
>>something I picked up during my general kernel "research" and I
>>found it to be a easy way of solving this particular problem.
>
>Other people in this thread are taking the opposite stand-- they think
>that wading through the source code *is* the appropriate way to learn how
>to do such things. This kind of elitist "documentation is for dummies"
You don't seem to understand that having the source code is far better than
having documentation. In the proprietary world, you need documentation simply
because the source is not available, so people cling to the myth that
documentation is essential. Documentation isn't for dummies, it's for people
without source code. It's not an elitist assumption that developers can
understand source code.
Many programmers, like me, maintain code that is poorly documented, if at all.
Yet it doesn't bother them. Where they need documentation is at the boundary
between the software and the proprietary system interfeces that it uses. In
the open source world, you can simply view the library and the kernel as being
an integral part of your application. You do not bottom out at some proprietary
software layer that you cannot navigate without documentation.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux,comp.os.linux.misc
Subject: Re: Need to find my IP address
Reply-To: [EMAIL PROTECTED]
Date: Mon, 08 May 2000 01:46:09 GMT
On Sun, 07 May 2000 20:29:22 GMT, Chris <[EMAIL PROTECTED]> wrote:
>On Sat, 06 May 2000 22:12:59 GMT, [EMAIL PROTECTED] (Kaz Kylheku)
>wrote in comp.os.linux.development.apps:
>
>>Get real; these ioctl's are easy to find in the kernel source code.
>
>>I disagree on both counts. Having the operating system source code
>>is a blessing. I'd rather read ten lines of code than a thousand lines
>>of documentation.
>
>I'm heartened to know that you've uninstalled all the man pages from your
>system. After all, if you need to know the arguments to a standard C
>library call you can always go look in the libc6 sources....
Actually, you can often just look in the header files.
I prefer to use the online draft of The Single UNIX Specification as my handy
reference, simply to try to avoid making non-portable assumptions.
--
#exclude <windows.h>
------------------------------
From: C J Considine <[EMAIL PROTECTED]>
Subject: Re: Large File Support
Date: Sun, 07 May 2000 20:13:28 -0700
we use open64() and lseek64() on i386.
David E Allen wrote:
>
> In comp.os.linux.misc Marc SCHAEFER <[EMAIL PROTECTED]> wrote:
> : llseek() exists, it allows to do very large seeks on raw devices.
>
> This is perfect. I will be talking to a raw device (scsi). Thanks. Do I
> need to use a special open(2)? The man page says O_LARGEFILE is ignored.
> I'm just wondering if the driver will keep track of the 64 bits. I suppose
> if I always reference it to the beginning of the file, I won't have to
> worry about that. (I'm using a red hat 6.2, kernel is 2.2.14-5.00.)
>
> dave allen, colorado springs
------------------------------
From: GENE <[EMAIL PROTECTED]>
Subject: Re: A need for better insallation programs
Date: Mon, 08 May 2000 03:15:19 GMT
Cihl wrote:
> I think what this guy wants is something GUI-based, like Windows'
> InstallShield, right?
> Well, this tool is being ported to Linux right now. Let's see how it handles
> things.
>
> B.t.w. I -did- see a nifty little install-tool with JBuilder, called
> InstallAnywhere. Has anybody else seen it? It works even simpler than
> InstallShield, IMHO. Very nice, maybe this could be used more.
Yeah, I just installed JBuilder 3.5 today, and the couple or so packages that
used InstallAnywhere went flawlessly. Nice installer!
Gene Montgomery
------------------------------
Reply-To: "Mark Graybill" <[EMAIL PROTECTED]>
From: "Mark Graybill" <[EMAIL PROTECTED]>
Subject: Re: malloc more than the mem available ?
Date: Mon, 08 May 2000 04:11:29 GMT
Olivier Spielmann wrote in message <[EMAIL PROTECTED]>...
>Hi,
>
>I am using RH 5.2 kernel 2.2.3. My amount of RAM is 128 MB and my swap
>space is 128 MB. I have just written a small application to understand
>better the malloc behaviour.
>
>The application allocate with malloc 2 times 200 MB. How come this is
>possible because my amount of RAM and swap is only 256 MB ? How is the
>kernel managing that kind of cases ? What happens if I fill this 2
>pointing memory spaces ?
Linux veterans correct me if I am wrong:
It sounds like you are only allocating memory, not using it.
It won't commit the allocated memory to physical resources until you try to
access that 400mb (memory is not really allocated.)
-Mark
------------------------------
From: Tim Roberts <[EMAIL PROTECTED]>
Subject: Re: what is "BSS"?
Date: Sun, 07 May 2000 21:55:09 -0700
Josef Moellers <[EMAIL PROTECTED]> wrote:
>JKFang wrote:
>>
>> What does it mean by "Cleaning BSS" ?
>> This question comes when reading some document about linux kernal.
>
>AFAIK "BSS" is an acronym for "block starting segment",
>whateverthatmeans.
It stands for "block starting at symbol". It was an pseudo-operation in
some assembler now shrouded in the mists of antiquity. I first encountered
it in the Control Data COMPASS assemblers from the mid-1960s, but I've
heard someone else claim it originated at IBM.
It was used thusly:
ABCD BSS 100
This would reserve a "block" of 100 words/bytes/units "starting at the
symbol" ABCD. In MASM, that's equivalent to:
ABCD DB 100 REP (?)
This ur-assembler also had "BES", "block ending at symbol", which would
sometimes be a handy thing to have.
--
- Tim Roberts, [EMAIL PROTECTED]
Providenza & Boekelheide, Inc.
------------------------------
From: Kenny Zhu Qili <[EMAIL PROTECTED]>
Crossposted-To: comp.programming.threads,comp.os.linux.networking
Subject: Help: Socket programming with Pthread
Date: 8 May 2000 05:04:52 GMT
Hi there. I'm programming internet tcp sockets with Linux pthread when I came across
this problem: the sockets which are created by mother thread and passed on to child
threads for communication would not close. They are all stuck in "CLOSE_WAIT" state.
The client side I'm using a Perl program which does a close() to close the socket. I
checked the kernel development archive and looks like up to kernel 2.2.5 this was
still a bug. I'm using 2.2.13, is it still a bug or my program is wrong? I'm
attachming a fragment of the program below. Please help me!
//In the parent thread...
while (1)
{
int* new_sock = new(int);
if ((*new_sock=accept(req_sock, (struct sockaddr*) &clnt_adr, &clnt_len))<0)
{
perror("Accept error");
close (req_sock);
exit (4);
}
pthread_create(&recep_threads[thread_index], NULL, receptalk, new_sock);
thread_index=(thread_index+1)%(MAX_NUM_CLIENTS/6);
//In the child thread receptalk...
... Some communication on socket new_sock ...
close(new_sock);
Kenny Zhu
~
------------------------------
Reply-To: "Mark Graybill" <[EMAIL PROTECTED]>
From: "Mark Graybill" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development,comp.os.linux.development.apps
Subject: Re: Two really easy (I'm sure) questions
Date: Mon, 08 May 2000 05:40:23 GMT
Alan Donovan wrote in message <[EMAIL PROTECTED]>...
>Mark Graybill wrote:
>
>> Although I have participated in other OS development projects, I am
>> new to Linux and have no experience with command shells.
>
>That explains it then. The Bourne shell (aka UNIX shell) is a complex
>beast, but very (very) much more useful than the joke command-line
>interpreter that comes with MS-DOS. People who confuse the two tend
>think UNIX is a dinosaur,
I agree with you about the shell, but not your blindly placing me in the
category of people described above.
DOS itself, is a joke - and always has been. There were real multi-tasking
OS's that humiliated DOS when it made it's appearance (e.g. Convergent
Technologies CTOS.)
Unfortunately, many advanced operating systems fell by the way side because
of their maker's marketing ineptitude.
>when, as anyone proficient in shell will tell
>you, there are few, if any, more expressive languages for both scripting
>programs and interactive use.
I agree with you in shell scriptings capabilities, but your experience with
"languages for both scripting programs and interactive use" is obviously
limited here (the mainframes have had scripting languages that puts shell in
its place.)
>It is also very important to understand the role of the shell in a UNIX
>system if you want to make it as a programmer. Implicit in this is
>understanding the difference between system and fork, and how file
>redirection, command-line processing, job control, etc all work. Read a
>good book or two on the design of UNIX.
Keep in mind Linux is not really unix - it is not a direct decendant of
unix. The following unix systems I've already studied and have experience
with: AT&T 3B2 System V, AIX, HP-UX, SCO, BSD, OSF1, mach kernel, and IBM
microkernel. What books would you recommend?
>
>> Since the underlying code is a shell, I wouldn't think it would be
calling
>> system calls for such things.
>
>The underlying code is not a shell. The command you are writing is
>interpreted directly by the shell. It is the shell that parses "2>&1",
>not gcc or make or anything else. What the shell does when it sees this
>is to duplicate the output filedescriptor stdout (using the dup2()
>system call) so that writes to stderr in the child program (gcc)
>actually go to the same file as stdout. Note that the file can be a real
>file (on disk), a pipe, a pseudofile (a device) or a terminal (where
>unredirected stdout/err go). Depending on your command line, any of
>these may be used.
>
>As Kaz said, 2>&1 is correct. 2<&1 is not, but it just happens to work
>because dup'ing an fd for write is the same as dup'ing for read.
You missed the "other OS development projects" above, didn't you? (I have
no experience *developing* command line shells - it's not a statement of my
experience using them.) Perhaps your assumptions are in error. :)
BTW, I still have no technical explanation as to why. Just as Kaz couldn't
tell me why it is bad practice to use void main() instead of int main().
Some of this stems from frustration with recent graduates that have come
into my projects who have ridiculously rigid do's and don'ts, and will not
change - even if they hinder productivity. I had one graduate student
graduate (sounds like chiasmus), who insisted it was "lazy" to use a task
list to select the window of a desired running program, and would waste time
clicking title bars to send windows to the back until she found the right
one (I've watched her miss the one she wanted in succession, and start the
process all over again, wasting time - especially mine.) These people were
also not very good team players because of their egos and propensity to
competition, and unwillingness to improve their skills - they hindered team
dynamics. Team playing is a requirement in today's IT. The lack of being a
good team player and willingness to improve your productivity are qualities
used to weed out candidates.
So these news threads are really manifestations of issues I have, where I am
really trying to prove a point to programmers that are great computer
scientists, but cling to practices they learned in school that they cannot
ratify - and they hinder their growth as professionals. They aren't willing
to let go of old dogma.
I guess after 20 years, I've lost all the bulls#!t "do's and don'ts" my
professors could never explain why. Based on what is real (and confidence
in my own intelligence to discern what axioms are valid regardless of my
professors' idioms), in the real world of commercial software engineering,
I've developed my own set of do's and don'ts. I use void main() if it suits
my purpose (especially in a test program), and I've used 2<&1 because it
suited my purpose. If we should use 2>&1, tell us why. (I could really
care less which one I use - actually I may even have remembered it
incorrectly and it just happened to work this way when I tried it to verify
it.)
Again - please explain in technical terms WHY 2<&1 (and void main()) is
incorrect. I'm looking for solid technical reasons - not ethical reasons.
Or are all we are really doing is showing off? :)
Thanks,
Mark
------------------------------
From: Mark Wilden <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux,comp.os.linux.misc
Subject: Re: Need to find my IP address
Date: Mon, 08 May 2000 08:02:44 +0100
Kaz Kylheku wrote:
>
> Many programmers, like me, maintain code that is poorly documented, if at all.
> Yet it doesn't bother them.
By this logic, of course, commenting is also unnecessary.
------------------------------
** 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
******************************
