Linux-Development-Sys Digest #77, Volume #7 Fri, 20 Aug 99 16:14:58 EDT
Contents:
Re: Why not C++ (Johan Kullstam)
Re: [Q] Parallel port access program permission (William Burrow)
Re: Why not C++ (Edwin Young)
Re: Calling a BIOS interrupt (Chris Butler)
Re: fork() question (Juergen Heinzl)
Re: most efficient way to zero out a partition? (Josef Moellers)
Re: Strupr for Linux (Paul D. Smith)
Re: Accessing user space memory in kernel mode. (Sami Tikka)
Re: X Windows developement (Tranceport)
Re: most efficient way to zero out a partition? (John Phillips)
Re: most efficient way to zero out a partition? (Frank Sweetser)
Re: X Windows developement (Grant Edwards)
Re: where's the source to init (Eric Hegstrom)
RAID mirrorset -- rebuild? ("Ted Pavlic")
Re: [Q] Parallel port access program permission (Victor Wagner)
----------------------------------------------------------------------------
From: Johan Kullstam <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 20 Aug 1999 09:25:08 -0400
David Schwartz <[EMAIL PROTECTED]> writes:
> Johan Kullstam wrote:
> >
> > true enough. however, mis- or dangerous- usage should be slightly
> > more awkward than safe usage. this is not so with C/C++.
>
> I think you are still asking for the impossible.
no. other languages do this.
> > it often takes more work to look at return values, errno and catch
> > exceptions than it does to simply ignore them.
>
> It always takes more work to deal with something than to
> ignore it.
> > in C the default
> > handler is no handler at all.
>
> I'm not sure I follow you, but I don't think this has anything to do
> with the language. In C, there is no notion of a 'handler', is
> there?
the signal system is a handler. by default, most signals interrupt
your program and kill it (think kill or ^C). you can change this
behavior by explicitly giving a handler. this handler can be
something that just ignores it.
it takes more work to ignore a sig-int than it does to just let ^C
terminate your program. the two lines you need to ignore (one
#include <signal.h> and one signal(SIG_INT,SIG_IGN);) are not hard to
type, but unless you want it, you don't type it.
consider a new function called `writeh' which is just like the libc
write but when it fails due to say disk being full, it would, by
default, print a line explaining that disk is full and terminate your
program. a user could override this and make it ignore it or handle
through an extra argument.
writeh(array, size, filedescriptor, handler)
where handler is an optional argument where by default, handler
would be print appropriate error text to stderr (e.g., disk full
error) and terminate the program.
most of the time, you'd use
writeh(array, size, filedescriptor);
which would give a nice error text.
to ignore, give NULL as the handler.
writeh(array, size, fd, NULL);
and it would be nice to be able put in a goto of some sort to do
something useful.
writeh(array, size, fd, goto disk_full);
and failed writes could jump to some recovery code.
this is framed as more a libc than C grammar issue, but one
could alter both in order to make things easier. the last one in
particular, would require new C grammar rules.
for effeciency, perhaps have a compiler option about safety. this way
kernels could run with safety off and no checks. and you could debug
a program by turning safety on. other languages do this. C doesn't.
> > C++ helps somewhat but i still find it
> > a royal pain in the ass to check and handle everything.
> Yes, it is a royal pain in the ass to religiously check for
> everything that might go wrong with everything that you
> do. _In_any_language_
it might be nice to have functions check for stuff automatically and
by default unless told otherwise. then it wouldn't be such a royal
pain. computers are great at filling the details. they don't get
tired of repitition. let the computer do the religious checking!
> It seems to be reality that you are upset with, not any particular
> language. :)
no. it's C and C way of doing things i am upset with.
> > i seem
> > especially prone to extra calls to dtors for my classes. many people
> > (myself included) assume they have disk space and do not always check
> > fwrite or putc.
>
> These things can all easily be solved if they bother you. If you don't
> like fwrite or putc, don't use them. Make your own functions that always
> check these things and call them. But you'll find that it's hard to make
> them, because what you do in case of the errors varies with how you are
> using the functions. You really do have to do one of two things:
>
> 1) Ignore the error cases and hope for the best, or
>
> 2) Consider every possible error case at every step and code the right
> behavior.
> Now, you can do either in C or C++. What is the third option?
3) terminate program on error unless you override by explicitly saying
you want to ignore problems or providing some recovery.
when a disk write fails, do you really want to continue blithely on
in ignorance of losing data? is this a good default behavior?
4) like lisp, you can ask the user what they wish to do.
--
johan kullstam
------------------------------
From: [EMAIL PROTECTED] (William Burrow)
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.hardware,comp.os.linux.misc,comp.os.linux.questions
Subject: Re: [Q] Parallel port access program permission
Date: 20 Aug 1999 15:02:17 GMT
Reply-To: [EMAIL PROTECTED]
On Thu, 19 Aug 1999 14:24:39 +0900,
YANAGIHARA <[EMAIL PROTECTED]> wrote:
>>Why not trying to read and write from /dev/lp0? Is your parallel port
>>not supported?
>The device which is connected to parallel port is not
>printer. It is a original electronic circuit board of my
>own making, so transaction protocol is different to printer.
>So I thought that inb/outb oparation is easier than opening
>/dev/lp0.
I think the newer 2.3 kernel has added something that lets you control
the parallel port better than /dev/lp0. See on Kernel Threads if it is
useful to you:
http://www.kt.opensource.org/
--
William Burrow -- New Brunswick, Canada o
Copyright 1999 William Burrow ~ /\
~ ()>()
------------------------------
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
From: Edwin Young <[EMAIL PROTECTED]>
Date: 20 Aug 1999 15:32:43 +0100
David Schwartz <[EMAIL PROTECTED]> writes:
> You really do have to do one of two things:
>
> 1) Ignore the error cases and hope for the best, or
>
> 2) Consider every possible error case at every step and code the right
> behavior.
>
> Now, you can do either in C or C++. What is the third option?
I guess the idea is to handle errors a little higher up the tree rather than
having to explicitly handle the errors at every level.
eg a standard (if rather badly written) C fubction could be
int foo()
{
fd = open("blah",O_RDONLY);
if(fd == -1)
{
return -1;
}
nbytes = read(buf,fd,1000);
if(nbytes == -1)
{
close(fd);
return(-1);
}
err = close(fd);
if(err == -1)
{
return(-1);
}
return 0;
}
the exception-based (C++) one would be
try{
foo();
}
except(err)
{
...
}
void foo()
{
file fd("blah",O_RDONLY); // throws an exception on failure
fd.read(buf,1000); // ditto
// file's destructor closes it on exit
}
This seems to me to have 2 advantages.
1) functions can return what you want instead of returning
an error code and modifying a pointer to the output.
2) you can handle errors higher up the tree(what you really care
about is that foo() failed, not exactly which function in foo()
went wrong).
Disadvantages:
1) If you want to handle errors at a very low level you end
up with lots of try{} blocks which are worse than if statements.
2) Exception handling is a disaster with objects which don't
have destructors (pointers to malloced memory, FILE *'s etc).
--
Edwin
------------------------------
From: [EMAIL PROTECTED] (Chris Butler)
Subject: Re: Calling a BIOS interrupt
Date: 19 Aug 1999 11:50:12 +0100
[comp.os.linux.development.system - Wed, 18 Aug 1999 18:23:41 +0200]
* Gregory wrote *
> Can I call a BIOS interrupt, like int 0x10 or something, in Linux?
No. BIOS interrupts are real-mode only.
> I heard that Linux saves informations of the BIOS at boottime.
> Is this true or not?
It gets all the information it needs from the BIOS at boot time (eg, HD
information, etc), before switching to protected mode.
--
Chris Butler
<[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Juergen Heinzl)
Subject: Re: fork() question
Date: Thu, 19 Aug 1999 20:08:02 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>"Rob" <[EMAIL PROTECTED] (X=y)> writes:
>
>> Hi, When I do a fork() like this code :
>>
>> pid = fork()
>>
>> if (pid==0) // Child process
>> {
>> some_routine(intparam, charptr);
>> exit(0);
>> }
>>
>> // rest of parent process...
>>
>> and the parent does a waitpid(...) to make sure the child doesn't
>> become a zombie.
>> Now, my question is, what exactly is copied from the parent to the
>> child process? I know file handles are copied to the child, but are
>> all global/local variables copied as well ? And what about pointers
>> pointing to allocated memory prior to the fork process, can a child
>> access this memory as well ?
>
>fork() creates an exact copy of the parent, except that the child does
>not inherit file locks and pending signals. I presume that "file handles"
>means file descriptors.
>
>> Does the above code work then ? I mean the params passed to the
>> function are those valid ?
>
>Yes.
... but ... do not use exit(), use _exit() in the child and see vfork()
too, although vfork() might or might not behave as fork() does.
Cheers,
Juergen
--
\ Real name : J�rgen Heinzl \ no flames /
\ EMail Private : [EMAIL PROTECTED] \ send money instead /
------------------------------
From: Josef Moellers <[EMAIL PROTECTED]>
Subject: Re: most efficient way to zero out a partition?
Date: Fri, 20 Aug 1999 07:47:08 +0200
Ronald Cole wrote:
> =
> I feel the need to zero out my /dev/sda10. It's a bit over 1-gig
> and so:
> =
> dd if=3D/dev/zero of=3D/dev/sda10
> =
> takes a *long* time. How would I figure out the optimal block size
> to get the job done in the shortest amount of time without resorting
> to trial-and-error?
dd uses a default block size of 512, so for each and every block of 512
bytes you have a system call and the setup and execution of a scsi
transfer.
Try increasing your block size, it'll make a tremendous improvement.
Josef
-- =
PS Die hier dargestellte Meinung ist die persoenliche Meinung des
Autors!
PS This article reflects the autor=B4s personal views only!
------------------------------
From: [EMAIL PROTECTED] (Paul D. Smith)
Subject: Re: Strupr for Linux
Date: 20 Aug 1999 11:02:03 -0400
Reply-To: [EMAIL PROTECTED]
%% ryan wishum <[EMAIL PROTECTED]> writes:
rw> Iam write a strupr function for Redhat linux and keep getting
rw> runtime error (segmentv Fault) when I try to restore the
rw> capatilize letter in the string.
The problem is not in your function but rather how you're calling it.
You're passing either an invalid pointer, or a pointer to read-only
memory (remember that you normally can't write to a static string, like
"hello").
Since you don't give a complete example with the invocation, there's not
much we can do to help.
--
===============================================================================
Paul D. Smith <[EMAIL PROTECTED]> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
===============================================================================
These are my opinions---Nortel Networks takes no responsibility for them.
------------------------------
From: [EMAIL PROTECTED] (Sami Tikka)
Subject: Re: Accessing user space memory in kernel mode.
Date: Fri, 20 Aug 1999 00:00:12 +0300
Reply-To: [EMAIL PROTECTED]
On Mon, 16 Aug 1999 11:07:43 GMT, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>Which functions should i use to access user space memory in kernel
>mode?
Find an LDP (Linux Documentation Project) mirror and read the "Kernel
Hacker's Guide". It's been a while but I think it was called
"copy_from_user()" or something like that.
>How do i access the file system in from device driver?
I think someone once explained that this is impossible. To access the file
system you would need a thread of execution that can be put to sleep while
the fs is doing reading and writing. So, you'd need either a normal
user-space program and you'd use it to read/write for you or you can also
create a kernel process or thread like kflushd and kswapd.
--
Sami Tikka, [EMAIL PROTECTED], http://www.iki.fi/sti/
"One World, One Web, One Program" - Microsoft Promotional Ad
"Ein Volk, Ein Reich, Ein Fuhrer" - Adolf Hitler
------------------------------
From: Tranceport <[EMAIL PROTECTED]>
Subject: Re: X Windows developement
Date: Fri, 20 Aug 1999 18:00:46 GMT
> Just curious: which part? You have to write a server for an
> ASR33? You have to reimpliment xlib in COBOL?
You are right I did not ask the question the right way. I understand
that X is huge. I want to understand from a high level perspective what
components X is it made of, what do they do, how they interact together.
Usually books have references to other books, so from one general
overview book I will be able to dig in other resources.
In any case to answer your question, I have to develop Xaw (X athena
widgets, i think)
> Get some of the O'Reilly books for starters (the first couple
> volumes anyway). They cover moderately low level stuff like
> xlib. If you want to diddle at the X-protocol level, then I
> don't know where to point you.
Thanks for the suggestion. I'll take a look at them.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (John Phillips)
Subject: Re: most efficient way to zero out a partition?
Date: 20 Aug 1999 19:31:26 +0100
Josef Moellers <[EMAIL PROTECTED]> writes:
> Ronald Cole wrote:
>> =
>> I feel the need to zero out my /dev/sda10. It's a bit over 1-gig
>> and so:
>> =
>> dd if=3D/dev/zero of=3D/dev/sda10
>> =
>> takes a *long* time. How would I figure out the optimal block size
>> to get the job done in the shortest amount of time without resorting
>> to trial-and-error?
>
> dd uses a default block size of 512, so for each and every block of 512
> bytes you have a system call and the setup and execution of a scsi
> transfer.
> Try increasing your block size, it'll make a tremendous improvement.
Just increasing block size from 512 bytes to 1k bytes gets almost all
of the available improvement on this system.
--
John Phillips [EMAIL PROTECTED]
------------------------------
From: Frank Sweetser <[EMAIL PROTECTED]>
Subject: Re: most efficient way to zero out a partition?
Date: 20 Aug 1999 12:04:55 -0400
Ronald Cole <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Christopher Browne) writes:
> > I'd go with
> > dd if=/dev/zero of=/dev/sda10 bs=64k
> > which will chew up 65536 bytes at a shot.
> >
> > It's small enough that it's not liable to have any ill effects on
> > memory consumption. It's large enough that there shouldn't be nearly
> > as much overhead as with the 512 bytes that I suspect it defaults to.
>
> Actually, I just discovered that any bs greater than dd's defaults
> will lock up RedHat's linux-2.2.5-22smp.
what i would very highly recomend doing in your case -
- upgrade to the latest kernel, 2.2.11, soon to be 2.2.12 (you can find
the source at ftp://ftp.gz.us.kernel.org/pub/linux/kernel/ ) and see if
it still happens
- if it does, send off a bug report to linux-kernel at vger.rutgers.edu -
the kernel people would probably be interested in such a report.
--
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
Intel engineering seem to have misheard Intel marketing strategy. The phrase
was "Divide and conquer" not "Divide and cock up"
(By [EMAIL PROTECTED], Alan Cox)
------------------------------
From: grant@nowhere. (Grant Edwards)
Subject: Re: X Windows developement
Date: Fri, 20 Aug 1999 16:32:12 GMT
In article <7phn6n$ddr$[EMAIL PROTECTED]>, Tranceport wrote:
>I have to develop the X windows system and I would really appreciate
>suggestions regarding books or web sites about this.
>
>I said developing X window not developing WITH X window. It's not a
>mistake. I do have to develop a part of the X system and I have to find
>out how to go about it ASAP.
Just curious: which part? You have to write a server for an
ASR33? You have to reimpliment xlib in COBOL?
Get some of the O'Reilly books for starters (the first couple
volumes anyway). They cover moderately low level stuff like
xlib. If you want to diddle at the X-protocol level, then I
don't know where to point you.
--
Grant Edwards grante Yow! I don't know WHY I
at said that... I think it
visi.com came from the FILLINGS inmy
read molars...
------------------------------
From: Eric Hegstrom <[EMAIL PROTECTED]>
Subject: Re: where's the source to init
Date: Fri, 20 Aug 1999 09:44:31 -0700
Thanks guys. That clears the problem up nicely. I must have been in
rough shape yesterday 'cause I actually signed my name as "Linux" to the
email. An interesting case of anthropomorpization if you ask me (let's
see the spell checker figure that one out!).
Cheers,
Linux, er, um... I mean Eric
On Thu, 19 Aug 1999 18:54:50 -0700, Eric Hegstrom
<[EMAIL PROTECTED]> wrote:
>OK I feel like an idiot.
>
>I know the source to /sbin/init is somewhere on the second redhat disk
>but which package is it in. Is there an easy way to answer these
>questions myself.
>
>Cheers,
>Linux
>
--
Eric Hegstrom .~.
Senior Software Engineer /V\
Sonoran Scanners, Inc. // \\ L I N U X
[EMAIL PROTECTED] /( )\ >don't fear the penguin<
520-617-0072 x402 ^^-^^
------------------------------
From: "Ted Pavlic" <[EMAIL PROTECTED]>
Subject: RAID mirrorset -- rebuild?
Date: Fri, 20 Aug 1999 15:30:09 -0400
I'm posting this here because most of the other Linux newsgroups (judging by
their content) that I subscribe to are ready by users who probably wouldn't
be doing a lot with RAID. (I really don't think that I should be flamed for
that -- I'm giving you (person reading this) a complement)
Plus, RAID at kernel level is a new thing that might go here anyway.
My system: Red Hat Linux 6.0 with a 2.2.10-ac12 kernel
I just configured /dev/md0 on my system to be a mirrorset (RAID-1)
consisting of two drives. Well, I have a:
/dev/md0 --
/dev/sda2
/dev/sdb2
/dev/md1
/dev/sda3
/dev/sda3
And I've booted off of /dev/md0. I got booting and everything working great.
I'm very impressed with RAID. HOWEVER, as a test, I turned off my system...
unplugged /dev/sdb... and turned the machine back on. Everything came up as
I expected -- RAID-1 ran in degraded mode. Feeling pretty happy about
things, I halted the machine and plugged /dev/sdb back in. I turned the
machine on and was hoping to find that the kernel saw the drive with the
matching mirror sets and was going to go and resync so that my /dev/md0
wouldn't be in degraded mode anymore. HOWEVER, the kernel still loaded the
raid in degraded mode.
How do I resync the mirrorset? I should hope that resync'ing after a drive
dies is possible -- if it's not, I'd have to copy everything off of /dev/md0
onto another drive... re-create /dev/md0... and then copy everything back to
/dev/md0... and that would be an awful *LOT* of downtime to fix something
with "redundant" in its name.
Any ideas? I thought:
mkraid --force-resync
Might work... but --force-resync wasn't in the man page, and when I tried
it, it wanted to trash everything on /dev/md0.
Thanks for your help --
Ted
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Victor Wagner)
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.hardware,comp.os.linux.misc,comp.os.linux.questions
Subject: Re: [Q] Parallel port access program permission
Date: 18 Aug 1999 23:07:02 +0400
In comp.os.linux.misc YANAGIHARA <[EMAIL PROTECTED]> wrote:
: Hello, everybody.
: Please tell me about Parallel port access.
: I made parallel port access program. When ueser is root, I
: can successfully read and write binary to parallel port.
: But when ueser is not root, ``Segmentation Fault'' occur at
: inb/outb function. Tell me how to change this program's
: permission ? Or, do I have to do another action ?
: -- My program's abstract is following...
: 1) include header file ``asm.h''
: 2) get 3 ports permission from base address of available
: parallel port by permio().
: 3) read by inb(), or write by outb().
: (root is local Linux machine's root, and other users are
: NIS account which are administered by Solaris NIS server.)
Trying to manage some strange parallel port device, aren't you?
Really there are two ways to go:
1. The right way
convert your program to kernel driver, which provides some special
file in /dev, which can be accessed by read/write and suitable ioctl
operations.
Linux kernel now have special provisions for multiple devices on
parallel port, so read parport docs in kernel.
Then write a program which provides interface with your device file
for users and control user access by permissions on your special file
in /dev.
If your device is widespread enough - say, parallel scanner and you
open your driver code, many people would be grateful to you
2. The quick and dirty way
Read a section about "Changing process persona" in info libc
Make your program setuid root and make call to seteuid(getuid())
just after calling ioperm.
Than make your program owned by root and chmod u+s it.
Now your program would start with effective uid root, and thus be
allowed to do permio. After it take permissions to read/write ports,
it would give up root privileges and continue to work as invoking
user, retaining rights to use ports.
Of course, having yet another suid-root prog is not good, but
it would do the job.
--
========================================================
Victor Wagner @ home = [EMAIL PROTECTED]
I don't answer questions by private E-Mail from this address.
------------------------------
** 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
******************************
