Linux-Development-Sys Digest #970, Volume #6 Sat, 17 Jul 99 00:14:14 EDT
Contents:
Re: Unix queues IPC? (bill davidsen)
Re: Help with RAID driver (bill davidsen)
Re: Bug of GCC (bill davidsen)
Re: when will Linux support > 2GB file size??? (bill davidsen)
Re: IO Completion Ports (Holy Cow)
Re: NCR 53C710 Fast SCSI-2 Controller (bill davidsen)
Re: Bug of GCC (bill davidsen)
Re: Bug of GCC (bill davidsen)
Where is IDE UDMA source? (Philip Brown)
Re: NCR 53C710 Fast SCSI-2 Controller (Johan Kullstam)
put_fs_byte (Bruce Kwan)
Re: NT to Linux port questions (Emile van bergen)
Re: Bug of GCC ("Alexei Boukirev")
Re: Bug of GCC (Isaac)
Re: NCR 53C710 Fast SCSI-2 Controller (Philip Brown)
Re: Why we are still holding on to X Windows (Christopher Browne)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Subject: Re: Unix queues IPC?
Date: 16 Jul 1999 21:10:15 GMT
In article <7mk6rn$afd$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
| Are kernel parameters that regulate number of
| messages, total messages size per queue, and per
| system configurable as they are on sysV4.2
| (unixware 2.1)? There I have settings with max
| 128K per queue, and 1Meg in total for queues. I
| would not mind having more, but less could pose
| some problems ;)
>From memory, msg.h, capability.h and sysctl.h in the linux include
directory. Grep is your friend, this can be set.
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
The Internet is not the fountain of youth, but some days it feels like
the fountain of immaturity.
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Subject: Re: Help with RAID driver
Date: 16 Jul 1999 21:12:10 GMT
In article <[EMAIL PROTECTED]>,
Michael L. DePolis <[EMAIL PROTECTED]> wrote:
| I have a dell poweredge 4300, need to Install Red Hat linux on it (5.2
| or 6.0). This server has a
| PERC2 quad channel RAID controller, which even Dell doesn't have a
| driver for. Does anyone know of one or a
| substitute driver that may work?
I just ordered that controller in a Dell machine (6500 I believe) and I
was told it was supported by Linux. If it isn't I have a complaint
coming!
However, if you find out anything on this, do let me know.
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
The Internet is not the fountain of youth, but some days it feels like
the fountain of immaturity.
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Subject: Re: Bug of GCC
Date: 16 Jul 1999 21:14:45 GMT
In article <[EMAIL PROTECTED]>,
Stuart MacDonald <[EMAIL PROTECTED]> wrote:
| Ross Smith <[EMAIL PROTECTED]> wrote in message
| news:[EMAIL PROTECTED]...
| > Because that's what the C/C++ standards say. Tokenisation takes place
| > before preprocessing. Comments are lost at the tokenisation stage, so
| > anything can go between /* and */. But anything between #if 0 and #endif
| > has to consist of valid preprocessing tokens.
|
| Not much of a *pre*processor then is it?
It works as documented, not as we might wish. If you want to write stuff
like this, use m4.
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
The Internet is not the fountain of youth, but some days it feels like
the fountain of immaturity.
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: when will Linux support > 2GB file size???
Date: 16 Jul 1999 20:49:19 GMT
In article <7mh77q$2ifb$[EMAIL PROTECTED]>,
Leslie Mikesell <[EMAIL PROTECTED]> wrote:
| >That's why I believe a different filesystem with 64 bit support and most likely
| >a different interface wrapper may be in order to minimize the performance hit.
|
| It didn't appear to make a measurable difference when the *BSD's added
| large file support years on 32 bit machines years ago. Why do people
| imagine it would be different with Linux?
Most of us don't. A few us of CPU added to an i/o measured in ms is
noise. Unless someone is doing lots of seeks and no i/o, in which case
they have other problems.
The real issue (as others have noted) is that mmap() won't work in any
reasonable way, and there isn't an obvious easy solution. The regular
i/o stuff, open, close, *seek and *tell could probably be faked, and I
suspect that *stat() stuff could as well, as long as everything was
recompiled properly.
I don't see any easy fix for mmap(), any fix would include 64 bit
subscripts in many places, and I think that *would* be a performance hit
of vast impact.
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
The Internet is not the fountain of youth, but some days it feels like
the fountain of immaturity.
------------------------------
From: Holy Cow <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: IO Completion Ports
Date: Fri, 16 Jul 1999 17:27:32 +0600
Matthew Carl Schumaker wrote:
>
> I've been trying to find info about IO completion ports under linux
I never heard of this under linux--it's an NT thing. Doesn't 'select' do
kind of similar something?
--
len
if you must email, reply to:
len bel at world net dot att dot net (no spaces, ats2@, dots2.)
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Crossposted-To: comp.os.linux.hardware
Subject: Re: NCR 53C710 Fast SCSI-2 Controller
Date: 16 Jul 1999 20:59:16 GMT
In article <[EMAIL PROTECTED]>,
Mike Coakley <[EMAIL PROTECTED]> wrote:
| Thanks for the response. I have gone through expert mode and made sure that
| the 53c7,8xx.o module is the one loading. (Using ALT-F3 and ALT-F4 give you
| a wealth of information during installation.) Is there some generic SCSI
| module that I can try. (I think I have tried all of the available modules
| though.)
I would try ncr53c8xx before going into panic mode. Also note that most
computer shows will provide you with a supported controller for <$50,
either a generic NCR (if PCI) or a AHA154x if ISA.
Sometimes it's not worth the effort to fight getting a checp card to
work.
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
The Internet is not the fountain of youth, but some days it feels like
the fountain of immaturity.
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Subject: Re: Bug of GCC
Date: 16 Jul 1999 21:18:25 GMT
In article <7mm9un$829$[EMAIL PROTECTED]>,
Cute Panda <[EMAIL PROTECTED]> wrote:
| Lots of preprocessors, like MS VC++, Sunsoft Workshop, IBM and HP, they
| don't complain about
| "#if 0 ... It's a bug .... #endif", only gnu preprocessor complains about
| this code.
Quality of implementation... they're broken.
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
The Internet is not the fountain of youth, but some days it feels like
the fountain of immaturity.
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Subject: Re: Bug of GCC
Date: 16 Jul 1999 21:24:36 GMT
In article <7mnbjt$987$[EMAIL PROTECTED]>,
Scott Lanning <[EMAIL PROTECTED]> wrote:
| Okay, let me recapitulate...
|
| 1) Cute Panda wondered why the GNU C preprocessor doesn't allow
| you put an apostrophe inside an #if 0 .. #endif.
|
| 2) The reply was based on the premise that, it is not allowed
| by standard C.
|
| 3) I argued with that premise, giving examples in which the
| GNU C preprocessor doesn't conform to standard C.
|
| If an argument is based on false premises, then the argument
| is invalid. This is basic logic. I thought it was generally
| accepted that one uses logic when debating things, but,
| I guess I forgot I was on Usenet. My bad...
So on point three, you are arguing that because gcc doesn't meet all
points of the standard (I assume you use -ansi and -pedantic), it
shouldn't do something else right? Isn't that a little like saying that
if your car pings on bad gas it shouldn't warn you when you're low on
oil?
I see no (logical) way to argue that because gcc has other flaws it
should have this one as well.
Now if you argue that the places where it doesn't match the standard
should fixed...
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
The Internet is not the fountain of youth, but some days it feels like
the fountain of immaturity.
------------------------------
From: [EMAIL PROTECTED] (Philip Brown)
Subject: Where is IDE UDMA source?
Reply-To: [EMAIL PROTECTED]
Date: 16 Jul 1999 22:43:39 GMT
Okay, I'm not a linux kernel guru. Could someone tell me whereabouts to get
the part of the kernel source that handles UDMA disk transfers? And I really
hope there is C code to do this. Because the only kernel source related stuff
I've found so far, is "syslinux-1.42", and that seems to just be a bunch of
ASM.
--
[Trim the no-bots from my address to reply to me by email!]
[ Do NOT email-CC me on posts. Pick one or the other.]
--------------------------------------------------
The word of the day is mispergitude
------------------------------
Crossposted-To: comp.os.linux.hardware
Subject: Re: NCR 53C710 Fast SCSI-2 Controller
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: 16 Jul 1999 18:59:22 -0400
[EMAIL PROTECTED] (bill davidsen) writes:
> In article <[EMAIL PROTECTED]>,
> Mike Coakley <[EMAIL PROTECTED]> wrote:
>
> | Thanks for the response. I have gone through expert mode and made sure that
> | the 53c7,8xx.o module is the one loading. (Using ALT-F3 and ALT-F4 give you
> | a wealth of information during installation.) Is there some generic SCSI
> | module that I can try. (I think I have tried all of the available modules
> | though.)
>
> I would try ncr53c8xx before going into panic mode. Also note that most
> computer shows will provide you with a supported controller for <$50,
> either a generic NCR (if PCI) or a AHA154x if ISA.
they will? all the computer shows i've been to have never heard
anything non-adaptec when it comes to scsi adapter cards.
> Sometimes it's not worth the effort to fight getting a checp card to
> work.
--
J o h a n K u l l s t a m
[[EMAIL PROTECTED]]
Don't Fear the Penguin!
------------------------------
From: Bruce Kwan <[EMAIL PROTECTED]>
Subject: put_fs_byte
Date: Fri, 16 Jul 1999 15:29:17 -0700
Hi-
I have a program that uses put_fs_byte() and get_fs_byte
that compiles fine when using RedHat 5.2 but under RedHat 6.0,
these macros don't seem to be defined. Does anybody know
what I might need to do to update my code to run under
RedHat 6.0 using these calls?
Thanks!
Bruce
--
Bruce Kwan
Jet Propulsion Laboratory Phone: (818) 354-9250
4800 Oak Grove Dr. MS 161-260 FAX: (818) 393-4643
Pasadena, CA 91109 Email: [EMAIL PROTECTED]
------------------------------
From: Emile van bergen <[EMAIL PROTECTED]>
Subject: Re: NT to Linux port questions
Date: Sat, 17 Jul 1999 01:12:27 +0200
On Fri, 16 Jul 1999, Michel Bardiaux wrote:
>Could you post an example of code using a select interrupted by a
>signal?
>I have tried to make that work, esp. with SIGCLD while select-ing on
>sockets,
>but the select never seems to be interrupted. I had to resort to
>repeated
>short selects followed by explicit "waitpid"s.
Don't know exactly if the signal should have a handler or not for select
to be interrupted. The man page says that select will return
EINTR on a _caught_ signal. Anyway, I sometimes use this approach:
int sigpipe[2]={-1,-1};
#define PIPE_R 0
#define PIPE_W 1
void sighandler(int signal)
{
if (sigpipe[PIPE_W]!=-1)
write(sigpipe[PIPE_W],&signal,sizeof(signal));
}
void my_main_func()
{
fd_set fds;
int ret,sig;
if (pipe(sigpipe)) { perror("pipe()"); exit(1); }
/* N.B. Don't forget to install sighandler here as the handler for
the appropriate signals! Use your own preferred method. */
while(1)
{
FD_ZERO(&fds);
FD_SET(funkyfd,&fds); /* whatever. */
FD_SET(sigpipe[PIPE_R],&fds);
do
ret=select(max(funkyfd,sigpipe[PIPE_R])+1,&fds,0,0,0);
while(ret==-1 && errno==EINTR);
if (ret==-1) { perror("select()"); exit(1); }
if (ret==0)
{
printf("Timeout occured (pretty strange, huh?)\n");
}
if (FD_ISSET(funkyfd,&fds))
{
printf("Funkyfd is ready for reading\n");
}
if (FD_ISSET(sigpipe[PIPE_R]))
{
ret=read(sigpipe[PIPE_R],&sig,sizeof(sig));
if (ret==-1) { perror("read"); exit(1); }
if (ret!=sizeof(sig)) { fprintf(stderr,"pipe framing error\n");
exit(1); }
printf("Signal %d caught!\n",sig);
}
}
}
--
M.vr.gr. / Best regards,
Emile van Bergen (e-mail address: [EMAIL PROTECTED])
This e-mail message is 100% electronically degradeable and produced
on a GNU/Linux system.
~
~
:wq
------------------------------
From: "Alexei Boukirev" <[EMAIL PROTECTED]>
Subject: Re: Bug of GCC
Date: Fri, 16 Jul 1999 19:13:42 -0500
OK,
consider this
#if 0
"garbage
#endif
"; // end of string
/*
more garbage
#endif
*/ // end of comment
#endif
Which of these is TRUE #endif ? How do you know without tokenizing of
what's inside?
Regards,
Alexei Boukirev
Cute Panda <[EMAIL PROTECTED]> wrote in message
news:7mmjoe$kmi$[EMAIL PROTECTED]...
> If it's the way ANSI C is specified, then why the other preprocessor
> don't suffer this
> problem ? they don't meet the ANSCI standard, right ?
>
> Many books talk about this code and say it's a simple way to make
> comments, and lots of
> programmers write their code like this, well, I think it's very
inconvenient
> for some people
> to modify their code just because gcc preprocessor complains about this
kind
> of code.
>
> if gcc preprocessor is able to recognize "#if 0", then it should know
> that all the following
> code before #endif is not real code and should not be tokenized, why is it
> necessary to break the
> text into tokens ? don't you think tokenizing the text inside #if 0 ...
> #endif is a redundant job ?
>
>
>
>
> Ulrich Drepper ���g��峹 ...
> >"Cute Panda" <[EMAIL PROTECTED]> writes:
> >
> >> Lots of preprocessors, like MS VC++, Sunsoft Workshop, IBM and HP, they
> >> don't complain about
> >> "#if 0 ... It's a bug .... #endif", only gnu preprocessor complains
> about
> >> this code.
> >
> >And your point is? It's still no valid code.
> >
> >--
> >---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace
> >Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
> >Cygnus Solutions `--' drepper at cygnus.com `------------------------
>
>
------------------------------
From: [EMAIL PROTECTED] (Isaac)
Subject: Re: Bug of GCC
Date: 17 Jul 1999 00:57:49 GMT
On 16 Jul 1999 21:18:25 GMT, bill davidsen <[EMAIL PROTECTED]> wrote:
>In article <7mm9un$829$[EMAIL PROTECTED]>,
>Cute Panda <[EMAIL PROTECTED]> wrote:
>
>| Lots of preprocessors, like MS VC++, Sunsoft Workshop, IBM and HP, they
>| don't complain about
>| "#if 0 ... It's a bug .... #endif", only gnu preprocessor complains about
>| this code.
>
>Quality of implementation... they're broken.
>
The standard doesn't require them to complain. Implementations which
accept the code and which reject such code are both standard compliant.
I don't see any particular advantage to accepting such code, so I don't
consider gcc deficient compared to the other compilers. I see only
trivial advantages to rejecting such code, so the fact that gcc
complains is also no big deal.
Probably from an implementation standpoint, it's simpler to design a
prepocessor which complains. Fine by me. Changing this is effort
best spent elsewhere.
Isaac
------------------------------
From: [EMAIL PROTECTED] (Philip Brown)
Crossposted-To: comp.os.linux.hardware
Subject: Re: NCR 53C710 Fast SCSI-2 Controller
Reply-To: [EMAIL PROTECTED]
Date: 17 Jul 1999 02:59:54 GMT
On 16 Jul 1999 18:59:22 -0400, [EMAIL PROTECTED] wrote:
>[EMAIL PROTECTED] (bill davidsen) writes:
>> ...
>> I would try ncr53c8xx before going into panic mode. Also note that most
>> computer shows will provide you with a supported controller for <$50,
>> either a generic NCR (if PCI) or a AHA154x if ISA.
>
>they will? all the computer shows i've been to have never heard
>anything non-adaptec when it comes to scsi adapter cards.
yeah, and major online places too. HOWEVER.
A nice person on the solaris newsgroup pointed out that
http://www.centrix-intl.com/
sells 8751Sp cards really cheap.
Damn. in fact, they just went DOWN from a month ago when I bought one :-/
$65
This gets you an adaptorwith both 50 and 68-pin connectors. Although the
"external" connecting is only 68pin, if you care about that.
--
[Trim the no-bots from my address to reply to me by email!]
[ Do NOT email-CC me on posts. Pick one or the other.]
--------------------------------------------------
The word of the day is mispergitude
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why we are still holding on to X Windows
Reply-To: [EMAIL PROTECTED]
Date: Sat, 17 Jul 1999 03:58:56 GMT
On Fri, 16 Jul 1999 10:31:24 +0200, Michel Bardiaux
<[EMAIL PROTECTED]> wrote:
>Philip Brown wrote:
>>
>> On Thu, 15 Jul 1999 20:03:33 +0200, [EMAIL PROTECTED] wrote:
>> >...
>> >Much more than tweaking. IIRC there is absolutely no way for the *client
>> >app*
>> >to supply a font, fonts have to be installed on a font server.
>>
>> you just contradicted yourself.
>>
>> The app can say "Add this font server to the font path"
>> The app can ALSO open a port and act as a font server.
>
>Yes, there are ways; but there is no *simple* X or Xt API for that; the
>client machine becomes
>a font server for the whole network, which breaks robustness and maybe
>security. It also breaks the basic X programming paradigm.
>
>In Windoze, one can pass data to the "rendering subsystem" (deliberately
>vague term) and say "This is the font to be used for this string". Much
>simpler (in principle! practically, Windoze has lotsa problems and
>technicalities!)
The problem here is architectural and administrative.
In Windoze, the whole system effectively runs in the same ring, which
means that if you need to fiddle with the set of fonts that are
available, you *can,* and permissions be darned.
[Application <-----> Graphics System <-----> Font Subsystem]
With X, things are more clearly compartmentalized, which has effects
both good and ill.
[X client] <----> [X Server] <----> [Font Server]
In order to get new fonts added, you need to add them to a font
server, and then "kick" it so that the X server can then provide them
to clients.
Two evils happen with X:
a) People commonly don't use a font server, which would allow
dynamically adding more fonts without restarting the X server, which
means that adding a font amounts to reconfiguring and restarting the X
server.
b) Connecting a new font server also requires reconfiguring (or at
least restarting) the X server.
In both cases, restarting the X server knocks down all applications
that were attached to it, which is a Bad Thing.
UNIX introduces a third problem:
c) All of these sorts of configuration tend to be assigned to root,
thereby discouraging "ordinary users" from having anything to do with
this.
What this implies is that the X server should be configured, on a
"user-administrated" system, to make use at least one font server that
is set up so that it may be reconfigured and restarted *by users.*
That isn't a "fix" to the problem; that is the *architecture* of the
fix...
--
In MDDT, no one can hear you scream...
But everybody can hear you say "whoops!"
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/xfonts.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
******************************
