Message: linux-kernel-digest V1 #1152
Sent: Sat, Sep 13, 1997 9:52 AM
To: Brett Terpstra
On Server: Student Mail
Date: Sat, Sep 13, 1997 2:02 PM
Reason: Could not be delivered because the destination Quarterdeck Mail server
could not be found.
<<<<<< Attached TEXT file named "linux-kernel-digest V1 #1152" follows >>>>>>
linux-kernel-digest Saturday, 13 September 1997 Volume 01 : Number 1152
In this issue:
Re: 2.0.29 and maximum number of user.
Re: Console mapping problems? [I hear about these - I wanna know!]
Re: how to tell if data is available for a file descriptor
Re: which AMD chips are bad - if anyone cares <g>
minor patch for 2.1.55 fs/inode.c
minor patch for 2.1.55 fs/pipe.c
minor patch for 2.1.55 fs/inode.c
minor patch for 2.1.55 fs/dcache
Re: 2.0.29 and maximum number of user.
Re: patch for 2.1.55 pre-1 minix/sysv/affs
Re: 3rd party drivers: Was Re: Kernel Geeks Unite?
Re: Console mapping problems? [I hear about these - I wanna know!]
Re: Console mapping problems? [I hear about these - I wanna know!]
Re: how to tell if data is available for a file descriptor
Re: linux 2.1.5[45] and PCI bus
Re: AIC7xxx problems
Re: Console mapping problems? [I hear about these - I wanna know!]
2.1.55 patch for Berkshire Products WDT
2.1.55 patch for sunrpc
Re: Console mapping problems? [I hear about these - I wanna know!]
Re: Console mapping problems? [I hear about these - I wanna know!]
Re: 2.1.54 __bad_fs_size() code missing
[2.1.52] slowness
connect() bug?
Re: pre-patch-2.0.31-9 OOPSs
Re: Linux-2.1.54..
Re: Memory leak in 2.1.54
Re: how to tell if data is available for a file descriptor
branch prediction hints (was Re: patch for 2.1.55 pre-1 minix/sysv/affs)
Re: how to tell if data is available for a file descriptor
Re: Console mapping problems? [I hear about these - I wanna know!]
Tasklist problems..
Re: /proc/pci design idea
See the end of the digest for information on subscribing to the linux-kernel
or linux-kernel-digest mailing lists.
----------------------------------------------------------------------
From: aem@netcom.ca
Date: Fri, 12 Sep 1997 16:51:42 -0400 (EDT)
Subject: Re: 2.0.29 and maximum number of user.
>> > BUZZZZ!!! Wrong. If you have 8 drives with a MTBF of 250,000 hours then
>> > the MTBF of a raid0 array is: 31250.. 1/8th.. A raid5 makes a failure
>> > virtually impossible.. (Of course someone could rm -r /; or kill the
>> > controler.. The controler can be replaced, and thats why there are
MTBF do not add. They are also statistical numbers based on
approximation under abnormal conditions more than real life
experience under normal operating conditions.
RAID-5 does not prevent drive failure - it helps to preserve data
in case of a failure.
Relying completely on RAID-5 to save your arse is foolish, as is
relying on a single backup.
Everything fails/dies sooner or later...usually sooner. And if
your job depends on it, it will fail the moment you schedule
some much needed vacation...
- --
Andrew E. Mileski
------------------------------
From: "Jon M. Taylor" <taylorj@ecs.csus.edu>
Date: Fri, 12 Sep 1997 14:01:58 -0700 (PDT)
Subject: Re: Console mapping problems? [I hear about these - I wanna know!]
On Wed, 10 Sep 1997, H. Peter Anvin wrote:
OK guys, you asked for it....
> > Yes - but device access MUST be _moderated_ by the kernel!
> > (unlike X)
> > But that's neither here nor now - and noone is likely to allow this into
> > the kernel even if it worked <sigh>. Been through that fight before
> > (though I was a spectator the last time).
>
> I disagree; an arbiter process (such as the X server) can do that just
> as well as the kernel.
No it cannot. Not even close.
> I think people are being too absolutist about
> this.
Sure, here we go again with the assertion that video hardware is
somehow so very very diferent from all other kinds of hardware in a
computer that it must be handled in a way that is markedly different (and
inferior). It is *quite* obvious to all of us involved in the GGI project
that this is very much not the case, and since we have been hacking the
kernel for over two years now I would say that we come from a far more
knowledgeable perspective on this issue than most on this list, at least
moreso than those who seem to not be able to resist GGI-bashing.
> Of course, the fact that the GGI people so far has failed to
> produce anything but hot air sort of reinforces that feeling....
Give me a break. When was the last time you looked at our code?
We have produced a hell of a lot more than hot air, and we'd be making
even more progress if people on this list would come work with us instead
of whining on this list when they need the odd bit of font setting or
whatever in the kernel.
The fact continues to remain that there is no other coding effort
in the Linux community relating to kernel graphics/console subsystem
revision that is anywhere close to as advanced as the GGI is now. We have
a very active mailing list, our source tree grows daily, progress is very
rapid these days and we have all the elements of a completely new and very
advanced and flexible console subsystem replacement already worked out.
Drivers are getting written, bugs are getting fixed, and progress is being
made.
We walk the walk while others merely talk the talk. We are not
afraid to defend the validity of our ideas (on this list or anywhere
else), and back them up with running code. Given the scope of the GGI
project (an almost total rewrite of the Linux console subsystem), we are
doing pretty damn well, thank you very much, especially when you consider
the almost total lack of cooperation and assistance we have recieved from
the rest of the core kernel development team (exceptions noted - we know
who you are and we thank you).
In conclusion, I suggest that everyone on this list go visit
http://synergy.foo.net/~ggi, read the FAQ, download the GGI source tree,
and educate themselves about this issue. It is NOT going to go away, and
neither are we.
Jon "GGI is The Right Thing To Do (TM)" Taylor
------------------------------
From: Dave Wreski <dave@nic.com>
Date: Fri, 12 Sep 1997 17:10:52 -0400 (EDT)
Subject: Re: how to tell if data is available for a file descriptor
> I have an open socket and a file descriptor
> for that socket, how do I tell without reading the
> data out of the buffer if there is data to be read?
man select()
Dave
------------------------------
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 12 Sep 1997 21:05:55 +0100 (BST)
Subject: Re: which AMD chips are bad - if anyone cares <g>
> CPUID 0x80000001
> Stepping ID : 2
> Model : 102
> Generation/Family : 6
Aha - does the magic K6 cpuid 0x80000001 change its model info between
the various B step K6's with/without bug ?
------------------------------
From: Bill Hawes <whawes@star.net>
Date: Fri, 12 Sep 1997 17:24:53 -0400
Subject: minor patch for 2.1.55 fs/inode.c
The attached patch fixes a couple of minor inode problems. It adds a
wakeup after clearing I_LOCK following read_inode, and repeats the call
to sync_one in write_inode_now to cover the case of the inode being both
dirty and locked.
BTW, I'm still a little uneasy with clearing I_LOCK without the
spinlock, but I haven't come up with a definite problem. On some
architectures the x &= mask construct would take several instructions;
if I_LOCK were tested from interrupt contexts, could this be a problem?
Regards,
Bill
------------------------------
From: Bill Hawes <whawes@star.net>
Date: Fri, 12 Sep 1997 17:26:49 -0400
Subject: minor patch for 2.1.55 fs/pipe.c
This is a multi-part message in MIME format.
- --------------0D75AA0760BA8AFEADD10E60
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
This patch removes a little unnecessary code -- since pipes can't be
hashed, we don't need to mark them dirty.
Regards,
Bill
- --------------0D75AA0760BA8AFEADD10E60
Content-Type: text/plain; charset=us-ascii; name="pipe_55-patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="pipe_55-patch"
- --- fs/pipe.c.old Wed Sep 10 09:21:27 1997
+++ fs/pipe.c Thu Sep 11 08:49:38 1997
@@ -396,13 +396,6 @@
PIPE_RD_OPENERS(*inode) = PIPE_WR_OPENERS(*inode) = 0;
PIPE_READERS(*inode) = PIPE_WRITERS(*inode) = 1;
PIPE_LOCK(*inode) = 0;
- - /*
- - * Mark the inode dirty from the very beginning,
- - * that way it will never be moved to the dirty
- - * list because "mark_inode_dirty()" will think
- - * that it already _is_ on the dirty list.
- - */
- - inode->i_state = I_DIRTY;
inode->i_mode = S_IFIFO | S_IRUSR | S_IWUSR;
inode->i_uid = current->fsuid;
inode->i_gid = current->fsgid;
- --------------0D75AA0760BA8AFEADD10E60--
------------------------------
From: Bill Hawes <whawes@star.net>
Date: Fri, 12 Sep 1997 17:27:47 -0400
Subject: minor patch for 2.1.55 fs/inode.c
This is a multi-part message in MIME format.
- --------------7D68E3B65DB4DA2B9DD38497
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
[Sorry, forgot the attachment]
The attached patch fixes a couple of minor inode problems. It adds a
wakeup after clearing I_LOCK following read_inode, and repeats the call
to sync_one in write_inode_now to cover the case of the inode being both
dirty and locked.
BTW, I'm still a little uneasy with clearing I_LOCK without the
spinlock, but I haven't come up with a definite problem. On some
architectures the x &= mask construct would take several instructions;
if I_LOCK were tested from interrupt contexts, could this be a problem?
Regards,
Bill
- --------------7D68E3B65DB4DA2B9DD38497
Content-Type: text/plain; charset=us-ascii; name="inode_55-patchette"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="inode_55-patchette"
- --- fs/inode.c.old Wed Sep 10 09:21:27 1997
+++ fs/inode.c Fri Sep 12 17:06:21 1997
@@ -224,5 +200,5 @@
if (sb) {
spin_lock(&inode_lock);
- - if (inode->i_state & I_DIRTY)
+ while (inode->i_state & I_DIRTY)
sync_one(inode);
spin_unlock(&inode_lock);
@@ -482,4 +584,5 @@
*/
inode->i_state &= ~I_LOCK;
+ wake_up(&inode->i_wait);
return inode;
- --------------7D68E3B65DB4DA2B9DD38497--
------------------------------
From: Bill Hawes <whawes@star.net>
Date: Fri, 12 Sep 1997 17:29:54 -0400
Subject: minor patch for 2.1.55 fs/dcache
This is a multi-part message in MIME format.
- --------------FA829826CA97B56FF2D866BA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
The attached patch checks the memory allocation in d_alloc_root, and
fills in the correct hash for a root qstr.
Regards,
Bill
- --------------FA829826CA97B56FF2D866BA
Content-Type: text/plain; charset=us-ascii; name="dcache_55-patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="dcache_55-patch"
- --- fs/dcache.c.old Sat Sep 6 16:03:33 1997
+++ fs/dcache.c Fri Sep 12 09:39:08 1997
@@ -211,7 +232,9 @@
if (root_inode) {
- - res = d_alloc(NULL, &(const struct qstr) { "/", 1, 0 });
- - res->d_parent = res;
- - d_instantiate(res, root_inode);
+ res = d_alloc(NULL, &(const struct qstr) { "/", 1, 47 });
+ if (res) {
+ res->d_parent = res;
+ d_instantiate(res, root_inode);
+ }
}
return res;
@@ -345,5 +368,5 @@
/*
- - * We cannibalize "newdentry" when moving dentry on top of it,
+ * We cannibalize "target" when moving dentry on top of it,
* because it's going to be thrown away anyway. We could be more
* polite about it, though.
- --------------FA829826CA97B56FF2D866BA--
------------------------------
From: Dave Wreski <dave@nic.com>
Date: Fri, 12 Sep 1997 17:50:27 -0400 (EDT)
Subject: Re: 2.0.29 and maximum number of user.
> It does work without recompiling libc if you have a newish version
> (I am running libc5.4.17). Note that I don't think that this patch
> is needed... it increases the FD's per-process (ie if you were running
> squid, which is one process with lots and lots of filehandles
> in use), which you don't need... you probably only need to increase the
overall
> filehandles/inodes, which you can do by simply echoing values to /proc...
I happen to be running squid on a soon-to-be production box, so I'm not
sure if it will be affected once 40 or so users start using it.
Will I see syslog messages indicating that the file limit has been
reached?
Why is that limit so low in the first place?
Thanks,
Dave
------------------------------
From: Manong Dibos <jwalther@citytel.net>
Date: Fri, 12 Sep 1997 14:56:57 +0000 ( )
Subject: Re: patch for 2.1.55 pre-1 minix/sysv/affs
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.
- ---187955613-2032249575-874076217=:785
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Fri, 12 Sep 1997, Linus Torvalds wrote:
> Sure. We'd also be about 500 times slower.
>
> Exception handling is _complex_. That translates into slow.
Ok, I agree the full fledged, regular OO exception handling (where
exceptions involve allocating "objects" and passing them up hierarchies to
find the right handlers) can be slow.
However, for the quick and dirty usage of exceptions (the most used I
think), Ive come up with these simple C macro's. Would anyone care to
check them out?
I believe they involve almost no performance hit over the conventional
nested if()'s......
To use the code, just #include "exceptions.h"
- --- exceptions.h ---
/* exceptions.h -- Macros to emulate exception handling in C
*
* September 11, 1997
* by Jonathan Walther jwalther@citytel.net
*
* Datatypes:
* an "exception" is actually an int.
* each thread gets one "int" dedicated to hold exception values called
* "e"
* Mappings between an integer value and what it "means" when thrown as
* an exception can vary between try{} statements. So that the ints
* you throw make sense, use #define's to give the int a meaning.
*
* Usage:
*
* #define FOO_ERR 3
*
* try
* // code
* if (foo) throw(FOO_ERR);
* // more code
* endtry
* catch(FOO_ERR)
* // handle it
* catch(BAR_ERR)
* // if it had been thrown, this would handle it
* finally
* // do this no matter what
* endcatching
*
* try, endtry, and endcatching are mandatory. The other clauses may be
* omitted.
*
* in the catch and finally clauses, more than one statement must be put
* in braces. eg,
*
* catch(FOO_ERR) blah(); endcatching // correct
* catch(FOO_ERR) blah(); bing(); endcatching // not correct
* catch(FOO_ERR) { blah(); bing(); } endcatching // correct
*
* Final note: Whenever you invoke "try", e is modified. If you wish to
* preserve the value, stash it in another variable.
*/
#define try e = 0; do {
#define throw(x) { e = x; break; }
#define endtry } while(0); if (e){ if (0) {}
#define catch(x) else if ( e == x )
#define finally } {
#define endcatching }
int e;
- --- end of exceptions.h ---
- ---187955613-2032249575-874076217=:785
Content-Type: TEXT/plain; name="exceptions.h"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.3.96.970912145657.785B@citytelprct53.citytel.net>
Content-Description:
LyogZXhjZXB0aW9ucy5oIC0tIE1hY3JvcyB0byBlbXVsYXRlIGV4Y2VwdGlv
biBoYW5kbGluZyBpbiBDDQogKg0KICogU2VwdGVtYmVyIDExLCAxOTk3DQog
KiBieSBKb25hdGhhbiBXYWx0aGVyICBqd2FsdGhlckBjaXR5dGVsLm5ldA0K
ICoNCiAqIERhdGF0eXBlczoNCiAqICBhbiAiZXhjZXB0aW9uIiBpcyBhY3R1
YWxseSBhbiBpbnQuDQogKiAgZWFjaCB0aHJlYWQgZ2V0cyBvbmUgImludCIg
ZGVkaWNhdGVkIHRvIGhvbGRpbmcgZXhjZXB0aW9uIHZhbHVlcyBjYWxsZWQg
ImUiDQogKiAgTWFwcGluZ3MgYmV0d2VlbiBhbiBpbnRlZ2VyIHZhbHVlIGFu
ZCB3aGF0IGl0ICJtZWFucyIgd2hlbiB0aHJvd24gYXMgYW4NCiAqICAgIGV4
Y2VwdGlvbiBjYW4gdmFyeSBiZXR3ZWVuIHRyeXt9IHN0YXRlbWVudHMuICBT
byB0aGF0IHRoZSBpbnRzIHlvdSB0aHJvdw0KICogICAgbWFrZSBzZW5zZSwg
dXNlICNkZWZpbmUncyB0byBnaXZlIHRoZSBpbnQgYSBtZWFuaW5nLg0KICoN
CiAqIFVzYWdlOg0KICoNCiAqICAjZGVmaW5lIEZPT19FUlIgMw0KICoNCiAq
ICB0cnkNCiAqICAgIC8vIGNvZGUNCiAqICAgIGlmIChmb28pIHRocm93KEZP
T19FUlIpOw0KICogICAgLy8gbW9yZSBjb2RlDQogKiAgZW5kdHJ5DQogKiAg
Y2F0Y2goRk9PX0VSUikNCiAqICAgIC8vIGhhbmRsZSBpdA0KICogIGZpbmFs
bHkNCiAqICAgIC8vIGRvIHRoaXMgbm8gbWF0dGVyIHdoYXQNCiAqICBlbmRj
YXRjaGluZw0KICoNCiAqIHRyeSwgZW5kdHJ5LCBhbmQgZW5kY2F0Y2hpbmcg
YXJlIG1hbmRhdG9yeS4gIFRoZSBvdGhlciBjbGF1c2VzIG1heSBiZSANCiAq
IG9taXR0ZWQuDQogKg0KICogaW4gdGhlIGNhdGNoIGFuZCBmaW5hbGx5IGNs
YXVzZXMsIG1vcmUgdGhhbiBvbmUgc3RhdGVtZW50IG11c3QgYmUgcHV0IGlu
DQogKiBicmFjZXMuICBlZywNCiAqDQogKiBjYXRjaChGT09fRVJSKSBibGFo
KCk7IGVuZGNhdGNoaW5nICAgICAgICAgICAgIC8vIGNvcnJlY3QNCiAqIGNh
dGNoKEZPT19FUlIpIGJsYWgoKTsgYmluZygpOyBlbmRjYXRjaGluZyAgICAg
Ly8gbm90IGNvcnJlY3QNCiAqIGNhdGNoKEZPT19FUlIpIHsgYmxhaCgpOyBi
aW5nKCk7IH0gZW5kY2F0Y2hpbmcgLy8gY29ycmVjdA0KICoNCiAqIEZpbmFs
IG5vdGU6ICBXaGVuZXZlciB5b3UgaW52b2tlICJ0cnkiLCBlIGlzIG1vZGlm
aWVkLiAgSWYgeW91IHdpc2ggdG8NCiAqIHByZXNlcnZlIHRoZSB2YWx1ZSwg
c3Rhc2ggaXQgaW4gYW5vdGhlciB2YXJpYWJsZS4NCiAqLw0KDQojZGVmaW5l
IHRyeSAgICAgICBlID0gMDsgZG8geyANCiNkZWZpbmUgdGhyb3coeCkgIHsg
ZSA9IHg7IGJyZWFrOyB9DQojZGVmaW5lIGVuZHRyeSAgICB9IHdoaWxlKDAp
OyBpZiAoZSl7IGlmICgwKSB7fQ0KI2RlZmluZSBjYXRjaCh4KSAgZWxzZSBp
ZiAoIGUgPT0geCApDQojZGVmaW5lIGZpbmFsbHkgICB9IHsNCiNkZWZpbmUg
ZW5kY2F0Y2hpbmcgfQ0KDQppbnQgZTsNCg0K
- ---187955613-2032249575-874076217=:785--
------------------------------
From: James Mastros <root@jennifer-unix.dyn.ml.org>
Date: Fri, 12 Sep 1997 17:22:11 -0400 (EDT)
Subject: Re: 3rd party drivers: Was Re: Kernel Geeks Unite?
On Wed, 10 Sep 1997, Stephen Williams wrote:
>
> root@jennifer-unix.dyn.ml.org said:
> > It would be wonderful if device makers would include linux drivers,
> > but it ain't gonna happen anytime soon.
>
> Not so. Picture Elements delivers linux drivers with our boards, as modules.
> However, we distribute them as source and the installation is a little bit
> harder then it needs to be.
Thank you! I should have been more specific. Large numbers of large
vendors aren't going to be makeing linux drivers any time to soon. (Take a
look at the number of "supported" things in MAINTAINERS.) Those that do we
all greatly thank; they have relised that Linux is a God amongst the Mear
Mortals of desktop OSes. (Yes, I did say Linux and not Linus. Not that
Linus isn't a God...).
> Some problems that I encounter are:
>
> - Kernel symbol versioning is too strict. (Not having some form of
versioning
> is too lax.) Type-safe linking of modules (a la C++)would be very helpful
> indeed, and pretty darn nifty.
Would a "function_foo_CHANGED" symbol be good? This symbol would be set to
the last kernel version that changed the interface of the function (or
varable). This would be more lax then current modversions (every kernel
comple), but less lax then encodeing the prototype (about equivlent to C++).
If the value of this is higher then what the module wants it, then we assume
that the module will screw.
> - Major number assignment. Seems like the assignment of major numbers should
> be a local problem, not a global one. Might I suggest that a range of
numbers
> be set aside as "locally assigned" and let kerneld straighten it out. If the
> module always takes major_number=<foo> and I can set up the aliases in
kerneld
> config files, major number assignment problems will go away. (Mass market
> devices can continue to use preassigned numbers.)
There are. See Documentation/devices.txt. However, kerneld can't
straighten it out; the major/minor needs to be published somehow. Perhaps
kerneld could be told to auto-select device {major,minor} number, and then
create a file in /dev/ matching the selected numbers.
> Yes, I will continue to ship driver source, but it would be nice to be
> able to include precompiled binaries, and install the driver with a few
> simple commands.
Da.
>
>
> Incidentally, there is a man9 project for keeping ddi man pages. We have
> a plausible set available at: <http://www.muppetlabs.com/~kirk/man9/>.
Cool. I'll have to stop by sometime!
> Steve Williams
-=- James Mastros
- ---
I can now be reached again at abszero@epix.net or
root@jennifer-unix.dyn.ml.org.
"Shooting as [a] communications method is obsolete even here in Bosnia, so
I'll skip over it."
-=- Dragisha Durich
------------------------------
From: James Mastros <root@jennifer-unix.dyn.ml.org>
Date: Fri, 12 Sep 1997 17:03:54 -0400 (EDT)
Subject: Re: Console mapping problems? [I hear about these - I wanna know!]
On Wed, 10 Sep 1997, Teunis Peters wrote:
> On Wed, 10 Sep 1997, H. Peter Anvin wrote:
> > Also would be very expensive in terms of kernel memory.
>
> The _FONT_ is loaded into the videocard - when necessary...
> ... this could be stored in virtual-mem and reloaded if necessary...
Somthing along the lines of setting the MMU to map the space where the VGA
card looks for the font into where the font for that terminal is? No-go --
the VGA card dosn't go through the MMU.
> Unfortunately, font reloading requires knowledge about the hardware. All
> I know about are:
> VGA - walk lightly - some cards aren't very nice (Trident 8900)
> [tested my code in S3-805,Trident 8900C/D,9660,S3-Trio64V+]
> - based on svgalib + XFree86 + vgadocs + demosources
Odd. The worst you should get is flashing. (With non-duel-ported memory).
> TGA - a snap. This is a graphical card - as a result the kernel
> does text here
> MDA - the (I've never seen one) text-only display for IBM-PC
I have. (It was born the same year I was, and that computer died already.
Sad.) It's font is in ROM, no change without a REALLY small soddering iron
<G>.
> CGA(/EGA?) - no font remapping... Assume IBM-PC chars
EGA font loading is identical to VGA (except for font height).
> Hercules - no font remapping... Assume IBM-PC chars
I wouldn't be surprised if it does, but I wouldn't know where to look.
> Other platforms? I always assumed they were all graphical...
>
> With the exception of MDA, building a graphical console rather than text
> is quite simple (see the TGA source in drivers/console). And with the
> exception of the Trident 8900 no special info really has to be known about
> the card (AFAIK).
A non-graphical console would deffenitly be better though. Better
resolution (lower mem requirements), faster (much handled by card, not CPU).
> Please don't say GGI - even though (if it worked <sigh>) that would be an
> ideal solution to font reloading.
True, true. Sigh...
> Perhaps there's a solution AKA kerneld for handling fonts/remapping?
> (it'd be pretty easy unlike kerneld - could pretty much be done from
> userspace with one (signal?) from the kernel - and two responses:
> [unsupported operation] or [OKAY])
Signal+data (what font). Also, giving a reason would be nice (bad font
number,
file not found, unable to access font buffer...), but I supose that you
could log the reason and just return "error" to the kernel.
> (actually - that would fit in well with what I want to do to the console :)
As in registering a different process to handle requests to change the font
for non-console terminals?
> > > > Uhmm... Loading/unloading fonts is ioctl, right? <sigh> - this makes
it
> > > > REALLY hard to emulate console under, say, X (I _REALLY_ don't like
> > > > Xterm's keyboard/display/font mapping).
> > >
> > > Yes, it's hard to emulate, but I know of no better way how to do it.
> >
> > Well there is escape sequences (very easy to emulate, works across
> > telnet etc.; disadvantage: makes it easy to utterly scramble someone
> > else's console.) That is a reasonable thing to do if it is
> > per-console.
You can do that now. Change the mapping, but not the font. Even just echo
"Screw you!" to it continually, so that the real output scrolls off to fast
to see. (Just tried this. VERY annoying!.) Either way, just type a command
blind, and the bother is gone (easyer in this case: "setfont", rather than
"/bin/echo \033]R" (reset palette from all black)). If you don't wan't this
to happen, "mesg n". It's a feature, not a bug.
>
> G'day, eh? :)
> - Teunis
>
-=- James Mastros
- ---
I can now be reached again at abszero@epix.net or
root@jennifer-unix.dyn.ml.org.
"Shooting as [a] communications method is obsolete even here in Bosnia, so
I'll skip over it."
-=- Dragisha Durich
------------------------------
From: "H. Peter Anvin" <hpa@transmeta.com>
Date: Fri, 12 Sep 1997 15:34:44 -0700 (PDT)
Subject: Re: Console mapping problems? [I hear about these - I wanna know!]
> > I think people are being too absolutist about
> > this.
>
> Sure, here we go again with the assertion that video hardware is
> somehow so very very diferent from all other kinds of hardware in a
> computer that it must be handled in a way that is markedly different (and
> inferior). It is *quite* obvious to all of us involved in the GGI project
> that this is very much not the case, and since we have been hacking the
> kernel for over two years now I would say that we come from a far more
> knowledgeable perspective on this issue than most on this list, at least
> moreso than those who seem to not be able to resist GGI-bashing.
It *is* quite different from all other hardware: the number of sources
involved and the bandwidth of the data streams make it a unique case.
However, when I say people are being too absolutist I mean both ways.
I'm quite happy going with whomever puts out the better solution
(XFree86 or GGI.) I'm just commenting on what I see.
> We walk the walk while others merely talk the talk. We are not
> afraid to defend the validity of our ideas (on this list or anywhere
> else), and back them up with running code. Given the scope of the GGI
> project (an almost total rewrite of the Linux console subsystem), we are
> doing pretty damn well, thank you very much, especially when you consider
> the almost total lack of cooperation and assistance we have recieved from
> the rest of the core kernel development team (exceptions noted - we know
> who you are and we thank you).
Given the vitriolic nature of the communications some of the GGI
project members have had from the very beginning most kernel
developers have written GGI off as a bunch of flukes. The flame from
about a year and a half ago ("we're going commercial" or something
like that) was the straw that broke the camel's back for a number of
people.
To be frank, I would be very hesitant to "defend the validity of
your ideas" in any *other* form than working code -- may it be fair or
not, you have exceeded your hot air quota by quite a bit. You are
fighting an uphill battle *because* of it, and adding more really
doesn't help, if you want your work to be judged fairly on its merits.
-hpa
------------------------------
From: "Michael H. Warfield" <mhw@wittsend.com>
Date: Fri, 12 Sep 1997 18:37:01 -0400 (EDT)
Subject: Re: how to tell if data is available for a file descriptor
> I have an open socket and a file descriptor
> for that socket, how do I tell without reading the
> data out of the buffer if there is data to be read?
Use select with a timeout of 0.
There may be other ways to do this but this is what I use and it's
real portable.
> please CC me directly,
> Thanks,
> Jerry
> I know read() tells me how many bytes were read etc...
> but it also takes the bytes out of the buffer.
Mike
- --
Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com
(The Mad Wizard) | (770) 925-8248 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
------------------------------
From: James Mastros <root@jennifer-unix.dyn.ml.org>
Date: Fri, 12 Sep 1997 18:47:49 -0400 (EDT)
Subject: Re: linux 2.1.5[45] and PCI bus
On Thu, 11 Sep 1997, Thorsten Kukuk wrote:
> Hello,
>
> since linux 2.1.54, the kernel will not found the PCI bus anymore.
> I have enabled:
> CONFIG_PCI=y
> CONFIG_PCI_BIOS=y
> CONFIG_PCI_DIRECT=y
> CONFIG_PCI_OPTIMIZE=y
>
> The boot message is:
> PCI: No PCI bus found.
Try forcing direct hardware access by disableing CONFIG_PCI_BIOS. If a PCI
bios is deteced AT ALL, it will be used. If your BIOS is very buggy, linux
might do a better job then it. Also, do you get any other PCI or bios32
error messages? And, lastly, what PCI chipset do you have?
-=- James Mastros
- ---
"Shooting as [a] communications method is obsolete even here in Bosnia, so
I'll skip over it."
-=- Dragisha Durich
------------------------------
From: Dave Wreski <dave@nic.com>
Date: Fri, 12 Sep 1997 19:10:42 -0400 (EDT)
Subject: Re: AIC7xxx problems
> Using module aic7xxx that is bundled with Caldera Open Linux Standard
> 1.1, (kernel ver. 2.0.29) everything works great in probing SCSI disks. When
the
> pre-2.0.31 kernel is used, SCSI1(Fuj) is detected as SCSI0 and SCSI0(Microp)
is
> not found using the AIC7xxx module.
Disable wide negotiation for that drive in the adaptec bios for now.
Dave
------------------------------
From: Teunis Peters <teunis@usa.net>
Date: Fri, 12 Sep 1997 16:21:01 -0600 (MDT)
Subject: Re: Console mapping problems? [I hear about these - I wanna know!]
On Fri, 12 Sep 1997, James Mastros wrote:
> On Wed, 10 Sep 1997, Teunis Peters wrote:
> > On Wed, 10 Sep 1997, H. Peter Anvin wrote:
> > > Also would be very expensive in terms of kernel memory.
> >
> > The _FONT_ is loaded into the videocard - when necessary...
> > ... this could be stored in virtual-mem and reloaded if necessary...
>
> Somthing along the lines of setting the MMU to map the space where the VGA
> card looks for the font into where the font for that terminal is? No-go --
> the VGA card dosn't go through the MMU.
I know - I thought of some kind of trigger (eg. change console) to trigger
font reload (which would be handled either by a specific routine - or
even better, in userspace).
> > Unfortunately, font reloading requires knowledge about the hardware. All
> > I know about are:
> > VGA - walk lightly - some cards aren't very nice (Trident 8900)
> > [tested my code in S3-805,Trident 8900C/D,9660,S3-Trio64V+]
> > - based on svgalib + XFree86 + vgadocs + demosources
> Odd. The worst you should get is flashing. (With non-duel-ported memory).
Trident goes hoopy (loses info about graphic res IIRC) if you don't handle
its fonts correctly.
> > TGA - a snap. This is a graphical card - as a result the kernel
> > does text here
> > MDA - the (I've never seen one) text-only display for IBM-PC
> I have. (It was born the same year I was, and that computer died already.
> Sad.) It's font is in ROM, no change without a REALLY small soddering iron
> <G>.
MDA still supported by linux :)
... but scary!
> > CGA(/EGA?) - no font remapping... Assume IBM-PC chars
> EGA font loading is identical to VGA (except for font height).
Thanks!
> > Hercules - no font remapping... Assume IBM-PC chars
> I wouldn't be surprised if it does, but I wouldn't know where to look.
> > Other platforms? I always assumed they were all graphical...
> >
> > With the exception of MDA, building a graphical console rather than text
> > is quite simple (see the TGA source in drivers/console). And with the
> > exception of the Trident 8900 no special info really has to be known about
> > the card (AFAIK).
> A non-graphical console would deffenitly be better though. Better
> resolution (lower mem requirements), faster (much handled by card, not CPU).
Yep - but in these days of fast accelerators et al, video-based console is
possible. 'sides, ever run 'kon' from the JE package? It's VGA based and
EXTREMELY fast (only slightly slower than hardware-based textmode).
It also supports large charactersets (EUC, JIS, SJIS)
> > Please don't say GGI - even though (if it worked <sigh>) that would be an
> > ideal solution to font reloading.
> True, true. Sigh...
I've been watching and annoyed with them - where is a coherent working
spec when you need it? I think they're going to complicated as well...
> > Perhaps there's a solution AKA kerneld for handling fonts/remapping?
> > (it'd be pretty easy unlike kerneld - could pretty much be done from
> > userspace with one (signal?) from the kernel - and two responses:
> > [unsupported operation] or [OKAY])
> Signal+data (what font). Also, giving a reason would be nice (bad font
number,
> file not found, unable to access font buffer...), but I supose that you
> could log the reason and just return "error" to the kernel.
Actually - Yeah, I suppose. But returning variety of error would be
important for error recovery (Very Important for console!)
> > (actually - that would fit in well with what I want to do to the console
:)
> As in registering a different process to handle requests to change the font
> for non-console terminals?
As in registering a process to take over from the console....
(handling display, fonts, et al).
> > > > > Uhmm... Loading/unloading fonts is ioctl, right? <sigh> - this
makes it
> > > > > REALLY hard to emulate console under, say, X (I _REALLY_ don't like
> > > > > Xterm's keyboard/display/font mapping).
> > > >
> > > > Yes, it's hard to emulate, but I know of no better way how to do
it.
> > >
> > > Well there is escape sequences (very easy to emulate, works across
> > > telnet etc.; disadvantage: makes it easy to utterly scramble someone
> > > else's console.) That is a reasonable thing to do if it is
> > > per-console.
> You can do that now. Change the mapping, but not the font. Even just echo
> "Screw you!" to it continually, so that the real output scrolls off to fast
> to see. (Just tried this. VERY annoying!.) Either way, just type a
command
> blind, and the bother is gone (easyer in this case: "setfont", rather than
> "/bin/echo \033]R" (reset palette from all black)). If you don't wan't this
> to happen, "mesg n". It's a feature, not a bug.
Okay - I can accept that :)
Can everyone else?
G'day, eh? :)
- Teunis
Sort of one last note : IIRC the console is kinda a 'special case' when it
comes to device support due to it being necessary before all of the device
support is setup.... is this possible to change?
Just curious....
------------------------------
From: Richard Gooch <rgooch@atnf.CSIRO.AU>
Date: Sat, 13 Sep 1997 10:01:31 +1000
Subject: 2.1.55 patch for Berkshire Products WDT
Hi, Linus. Can you please apply the following patch to 2.1.55? It
does similar fixups to the driver for the Berkshire Products watchdog
timer as did my patch for 2.0.30 which you applied. This one is even
better because it actually obeys CONFIG_WATCHDOG_NOWAYOUT.
Without this patch the watchdog has a nasty tendancy to do a delayed
reboot after you've started a reboot cycle: not fun when the kernel is
just starting to boot...
Regards,
Richard....
diff -urN linux-2.1.55/drivers/char/pcwd.c linux/drivers/char/pcwd.c
- --- linux-2.1.55/drivers/char/pcwd.c Thu Apr 24 12:01:17 1997
+++ linux/drivers/char/pcwd.c Fri Sep 12 18:22:41 1997
@@ -28,6 +28,7 @@
* drivers to panic the system if it's overheating at bootup.
* 961118 Changed some verbiage on some of the output, tidied up
* code bits, and added compatibility to 2.1.x.
+ * 970912 Enabled board on open and disable on close.
*/
#include <linux/module.h>
@@ -209,9 +210,6 @@
{
int wdrst_stat;
- - if (!is_open)
- - return;
- -
wdrst_stat = inb_p(current_readport);
wdrst_stat &= 0x0F;
@@ -235,6 +233,8 @@
"PCWD."
};
+ if (!is_open)
+ return -EIO;
switch(cmd) {
default:
return -ENOIOCTLCMD;
@@ -363,6 +363,8 @@
static long pcwd_write(struct inode *inode, struct file *file, const char
*buf, unsigned long len)
{
+ if (!is_open)
+ return -EIO;
if (len)
{
pcwd_send_heartbeat();
@@ -373,7 +375,13 @@
static int pcwd_open(struct inode *ino, struct file *filep)
{
+ if (is_open)
+ return -EIO;
MOD_INC_USE_COUNT;
+ /* Enable the port */
+ if (revision == PCWD_REVISION_C)
+ outb_p(0x00, current_readport + 3);
+ is_open = 1;
return(0);
}
@@ -383,6 +391,8 @@
unsigned short c = inb(current_readport);
unsigned char cp;
+ if (!is_open)
+ return -EIO;
switch(MINOR(inode->i_rdev))
{
case TEMP_MINOR:
@@ -397,7 +407,15 @@
static int pcwd_close(struct inode *ino, struct file *filep)
{
+ is_open = 0;
MOD_DEC_USE_COUNT;
+#ifndef CONFIG_WATCHDOG_NOWAYOUT
+ /* Disable the board */
+ if (revision == PCWD_REVISION_C) {
+ outb_p(0xA5, current_readport + 3);
+ outb_p(0xA5, current_readport + 3);
+ }
+#endif
return 0;
}
@@ -531,8 +549,6 @@
}
#endif
- - is_open = 1;
- -
#ifdef PCWD_BLIND
current_readport = PCWD_BLIND;
#endif
@@ -571,6 +587,11 @@
#ifdef MODULE
void cleanup_module(void)
{
+ /* Disable the board */
+ if (revision == PCWD_REVISION_C) {
+ outb_p(0xA5, current_readport + 3);
+ outb_p(0xA5, current_readport + 3);
+ }
misc_deregister(&pcwd_miscdev);
if (supports_temp)
misc_deregister(&temp_miscdev);
------------------------------
From: Richard Gooch <rgooch@atnf.CSIRO.AU>
Date: Sat, 13 Sep 1997 10:03:42 +1000
Subject: 2.1.55 patch for sunrpc
Hi, Linus. Can you please apply the following patch to 2.1.55?
Without this NFS as a module does not work.
Regards,
Richard....
diff -urN linux-2.1.55/net/sunrpc/sunrpc_syms.c linux/net/sunrpc/sunrpc_syms.c
- --- linux-2.1.55/net/sunrpc/sunrpc_syms.c Mon Apr 14 03:18:23 1997
+++ linux/net/sunrpc/sunrpc_syms.c Fri Sep 12 19:17:14 1997
@@ -74,7 +74,9 @@
/* RPC statistics */
#ifdef CONFIG_PROC_FS
EXPORT_SYMBOL(rpc_proc_register);
+EXPORT_SYMBOL(rpc_register_sysctl);
EXPORT_SYMBOL(rpc_proc_unregister);
+EXPORT_SYMBOL(rpc_proc_init);
EXPORT_SYMBOL(rpc_proc_read);
EXPORT_SYMBOL(svc_proc_register);
EXPORT_SYMBOL(svc_proc_unregister);
------------------------------
From: "Jon M. Taylor" <taylorj@ecs.csus.edu>
Date: Fri, 12 Sep 1997 17:43:45 -0700 (PDT)
Subject: Re: Console mapping problems? [I hear about these - I wanna know!]
On Fri, 12 Sep 1997, H. Peter Anvin wrote:
> > > I think people are being too absolutist about
> > > this.
> >
> > Sure, here we go again with the assertion that video hardware is
> > somehow so very very diferent from all other kinds of hardware in a
> > computer that it must be handled in a way that is markedly different (and
> > inferior). It is *quite* obvious to all of us involved in the GGI project
> > that this is very much not the case, and since we have been hacking the
> > kernel for over two years now I would say that we come from a far more
> > knowledgeable perspective on this issue than most on this list, at least
> > moreso than those who seem to not be able to resist GGI-bashing.
>
> It *is* quite different from all other hardware: the number of sources
> involved
I'm not sure what you mean by 'sources' here. Different
manufacturers? Different types of video I/O?
> and the bandwidth of the data streams make it a unique case.
OK, I will grant you this. But, *all* types of hardware have
their own unique peculiaries and must be handled differently. Indeed, the
bandwidth issue would seem to argue FOR kernel inclusion of video driver
code, since that code will be foundational and a lot of other kernel
subsections will interact with it. Those interactions can be much more
highly optimized and tweaked when the kernel-user barrier doesn't need to
be worked around. Look at NT 4.0. The video drivers weren't in the
kernel in 3.51, but were moved into the kernel in 4.0, and they got a LOT
of speed out of it.
> However, when I say people are being too absolutist I mean both ways.
> I'm quite happy going with whomever puts out the better solution
> (XFree86 or GGI.) I'm just commenting on what I see.
It hurts to be labeled an absolutist when we feel that we are
simply following established OS design principles.
> > We walk the walk while others merely talk the talk. We are not
> > afraid to defend the validity of our ideas (on this list or anywhere
> > else), and back them up with running code. Given the scope of the GGI
> > project (an almost total rewrite of the Linux console subsystem), we are
> > doing pretty damn well, thank you very much, especially when you consider
> > the almost total lack of cooperation and assistance we have recieved from
> > the rest of the core kernel development team (exceptions noted - we know
> > who you are and we thank you).
>
> Given the vitriolic nature of the communications some of the GGI
> project members have had from the very beginning most kernel
> developers have written GGI off as a bunch of flukes.
^^^^^^
I think you mean 'flakes' |->.
> The flame from
> about a year and a half ago ("we're going commercial" or something
> like that) was the straw that broke the camel's back for a number of
> people.
That was an off-the-cuff remark born out of frustration. GPLed
code cannot be 'taken commercial' in any case.
> To be frank, I would be very hesitant to "defend the validity of
> your ideas" in any *other* form than working code -- may it be fair or
> not, you have exceeded your hot air quota by quite a bit.
Indeed, and as I mentioned before I have, since the last GGI
flamewar on this list, made a point of not even *mentioning* the GGI on
this list - even when GGI-related issues came up, I bit my tounge and went
back to coding. However, I WILL NOT stand idly by when attacks on or
misstatements about the GGI are made, on this list or anywhere else. We
have enough work ahead of us without having everyone in the Linux
community considering us to be 'flakes' and 'full of hot air'.
Jon
------------------------------
From: "H. Peter Anvin" <hpa@transmeta.com>
Date: Fri, 12 Sep 1997 17:55:45 -0700 (PDT)
Subject: Re: Console mapping problems? [I hear about these - I wanna know!]
> I'm not sure what you mean by 'sources' here. Different
> manufacturers? Different types of video I/O?
Different data sources.
> > and the bandwidth of the data streams make it a unique case.
>
> OK, I will grant you this. But, *all* types of hardware have
> their own unique peculiaries and must be handled differently. Indeed, the
> bandwidth issue would seem to argue FOR kernel inclusion of video driver
> code, since that code will be foundational and a lot of other kernel
> subsections will interact with it. Those interactions can be much more
> highly optimized and tweaked when the kernel-user barrier doesn't need to
> be worked around. Look at NT 4.0. The video drivers weren't in the
> kernel in 3.51, but were moved into the kernel in 4.0, and they got a LOT
> of speed out of it.
> > However, when I say people are being too absolutist I mean both ways.
> > I'm quite happy going with whomever puts out the better solution
> > (XFree86 or GGI.) I'm just commenting on what I see.
>
> It hurts to be labeled an absolutist when we feel that we are
> simply following established OS design principles.
Well, there are a number of "established OS design principles" -- one
of them is "don't do it in kernel space unless you absolutely have
to." Linux has a problem with people trying to put way too many
things in kernel space, and putting a brake on that is usually
necessary.
> > The flame from
> > about a year and a half ago ("we're going commercial" or something
> > like that) was the straw that broke the camel's back for a number of
> > people.
>
> That was an off-the-cuff remark born out of frustration. GPLed
> code cannot be 'taken commercial' in any case.
>
> > To be frank, I would be very hesitant to "defend the validity of
> > your ideas" in any *other* form than working code -- may it be fair or
> > not, you have exceeded your hot air quota by quite a bit.
>
> Indeed, and as I mentioned before I have, since the last GGI
> flamewar on this list, made a point of not even *mentioning* the GGI on
> this list - even when GGI-related issues came up, I bit my tounge and went
> back to coding. However, I WILL NOT stand idly by when attacks on or
> misstatements about the GGI are made, on this list or anywhere else. We
> have enough work ahead of us without having everyone in the Linux
> community considering us to be 'flakes' and 'full of hot air'.
Speaking personally; maybe you guys ought to consider making status
summaries ("this is what we have so far") and post them. I think the
perception is still pretty widely spread that since you didn't get
unconditional approval from the start, you went off in a huff.
That is, if you care.
-hpa
------------------------------
From: Richard Henderson <rth@dot.cygnus.com>
Date: Fri, 12 Sep 1997 18:35:07 -0700 (PDT)
Subject: Re: 2.1.54 __bad_fs_size() code missing
> fs/fs.o: In function `write_dquot':
> fs/fs.o(.text+0x13543): undefined reference to `__bad_fs_size'
> fs/fs.o: In function `read_dquot':
> fs/fs.o(.text+0x13698): undefined reference to `__bad_fs_size'
> make: *** [vmlinux] Error 1
FYI, if you compile with -g, the linker will give you the
file and line number that the reference came from.
r~
------------------------------
From: "Pawel S. Veselov" <vps@unicorn.niimm.spb.su>
Date: Sat, 13 Sep 1997 06:04:25 +0400 (MSD)
Subject: [2.1.52] slowness
Hello, All !
Working under X and sending about 1.3Mb letter under pine ( pine completed
transferring this to sendmail ) I get a solid slowness - I could hardly move
mouse pointer. Switching to text terminal took about 30 seconds. I don't
know, what kernel was doing ( or what sendmail was doing in the kernel :)
because when I managed to log in on console, speed had returned. mailq said
mail still at spool, so it wasn't network sending...
So what was it ???
Bye.
- --
QOTD:
"East is east... and let's keep it that way."
- --
With best of best regards, Pawel S. Veselov (aka Black Angel)
internet : vps@unicorn.niimm.spb.su ( mail,finger,talk )
fidonet : 2:5030/5.412
schoolnet : 21:9000/412
Web page : http://www.niimm.spb.su/~vps/
------------------------------
From: James Mastros <root@jennifer-unix.dyn.ml.org>
Date: Fri, 12 Sep 1997 22:00:24 -0400 (EDT)
Subject: connect() bug?
Squid's config file has the comment:
# Some systems (notably Linux) can not be relied upon to properly
# time out connect(2) requests.
Does anybody know if this is still correct? I find no mention of this bug
on the connect(2) manpage, and I can't find connect in the kernel source at
all!
-=- James Mastros
- ---
"Shooting as [a] communications method is obsolete even here in Bosnia, so
I'll skip over it."
-=- Dragisha Durich
------------------------------
From: hans@grumbeer.inka.de (Hans-Joachim Baader)
Date: Fri, 12 Sep 97 23:37 MET DST
Subject: Re: pre-patch-2.0.31-9 OOPSs
In article <m0x920i-000CdYC@nevets.oau.org> you write:
>Someone mentioned that my old gcc (2.7.2) might be the cause of my OOPS's,
>so today I compiled the kernel on a RedHat 4.2 machine with gcc 2.7.2.1,
>and of course, I got a huge oops as soon as I started up trn. I'm running
>inn 1.5.1-6 and trn locally. Inn is fed via rnews via uucp batch.
[...]
>Meanwhile, my system has locked up when I wasnt home several times, so
>I'd declare at least this patched version of 2.0.31 very unstable. I
Hmm, this is just a wild guess, but take the following rule into
account:
RULE 1. If your system appears very unstable, try slower DRAM timings.
hjb
- --
Uncle Ed's Rule of Thumb: Never use your thumb for a rule.
You'll either hit it with a hammer or get a splinter in it.
------------------------------
From: Darryl Miles <dlm@g7led.demon.co.uk>
Date: Sat, 13 Sep 1997 01:32:15 +0100 (BST)
Subject: Re: Linux-2.1.54..
Hi,
If I've heard the Unix specification correctly applications are also broken
if they presume that the select timeout isn't modified and also if they
presume on how it has been modified. It's true to say "Applications should
consider the contents of the timeout to be undefined, after calling select(2)
use.".
This statement is obviously not true if you know extra information
on how it has been modified, in which case as no standard has defined how
to obtain this information then it's a platform specific issue, a Linux'ism
:-) and not what you're trying to address which is general software
portability.
How many broken commercial and non-commercial applications fall into
the area of presuming the timeout if not modified, even though the UNIX
specs now say that it maybe. If they are broken to start with then why are
we changing Linux policy, since these application will eventually be fixed
to confirm to the UNIX specification. AFAIK this fix (of reloading the
timeout every time, just before calling select(2)), then presuming nothing
about if after the syscall will make that application work with both Linux
(SLIPPY_TIMEOUTS) and DEC Unix (STICKY_TIMEOUTS).
You are advocating that it's broken applications which make use of
SLIPPY_TIMEOUTS, this is not true, yes it's a Linux'ism, but the application
using it is a Linux application, it has no interest or need to consider
other platforms. What you are really doing is bowing down to broken
application from other platforms, which presume the timeout is not modified.
Could I offer this (elegant, cough, cough) function as the basis for anyone
wanting to keep the old behavior.
It's arithmetic has had very little optimizational thought put on it.
I think if you rename the function to 'select' and rename the system calls
from 'select' to '__select' you may wrap your libc's select incarnation by
placing the resultant object code on the linker command line.
- ----------------------------------------------------------------------------
#include <stdio.h>
#include <time.h>
#include <sys/time.h>
#include <sys/types.h>
#include <unistd.h>
/* Number of usecs in one second */
#define TIMER_USEC_VAL 1000000
/* If you system doesn't support gettimeofday(), hah hah ha! */
int
linux_select(int maxfd, fd_set *readfd, fd_set *writefd, fd_set *exceptfd,
struct timeval *timeout)
{
int retval;
if(timeout != NULL) {
struct timeval otv;
struct timeval ntv;
gettimeofday(&otv, NULL);
retval = select(maxfd, readfd, writefd, exceptfd, timeout);
gettimeofday(&ntv, NULL);
if(retval != 0) {
long sec, usec;
long nsec, nusec;
sec = ntv.tv_sec - otv.tv_sec;
usec = ntv.tv_usec - otv.tv_usec;
/* If usec is negative then drop the second */
if(usec < 0) {
/* usec is negative and (1000000 + (-500000)) = 500000 :-)
*/
usec = TIMER_USEC_VAL + usec;
sec--;
}
/* We now have the select sleep duration in 'sec' and 'usec' */
nsec = timeout->tv_sec - sec;
nusec = timeout->tv_usec - usec;
if(nusec < 0) {
/* nusec is negative and (1000000 + (-500000)) = 500000 :-)
*/
nusec = TIMER_USEC_VAL + nusec;
nsec--;
}
if(nsec < 0) {
nsec = 0;
nusec = 0;
}
timeout->tv_sec = nsec;
timeout->tv_usec = nusec;
} else {
timeout->tv_sec = 0;
timeout->tv_usec = 0;
}
} else {
retval = select(maxfd, readfd, writefd, exceptfd, timeout);
}
return retval;
}
- ----------------------------------------------------------------------------
- --
Darryl Miles
------------------------------
From: James Mastros <root@jennifer-unix.dyn.ml.org>
Date: Fri, 12 Sep 1997 22:38:18 -0400 (EDT)
Subject: Re: Memory leak in 2.1.54
On Thu, 11 Sep 1997, linux kernel account wrote:
> On Wed, 10 Sep 1997, Chris Evans wrote:
> > Sorry for the "me too", but yes 2.1.54 leaks like a bucket.
>
> This has not been my expirence, the newer 2.1s seem to have memory happy
> dcache, but as there is a demand for memory the dcache will get pruned and
> your missing ram will return..
>
> Just my humble exp..
I had thought that to, but today I started a updateddb and got a scrolling
mass of "<filename>: out of memory" (or somesuch). I finally ended up
exiting netscape and running kill real fast, before the dcache sucked that
memory back up. (I have recently descovered that cat, ps and kill are all
dynamicly linked on my machice. I'll have to fix that eventually, but not
now.)
-=- James Mastros
- ---
"Shooting as [a] communications method is obsolete even here in Bosnia, so
I'll skip over it."
-=- Dragisha Durich
------------------------------
From: Jason Burrell <jburrell@crl5.crl.com>
Date: Fri, 12 Sep 1997 16:40:43 -0500 (CDT)
Subject: Re: how to tell if data is available for a file descriptor
On Thu, 11 Sep 1997, Geis Jerry wrote:
>
> I have an open socket and a file descriptor
> for that socket, how do I tell without reading the
> data out of the buffer if there is data to be read?
>
> please CC me directly,
> Thanks,
>
> Jerry
>
> I know read() tells me how many bytes were read etc...
> but it also takes the bytes out of the buffer.
The select() call should be appropriate.
select(int n, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, 0);
However, I noticed what looks like an error in my manpage over here.
timeout is an upper bound on the amount of time elapsed
before select returns. It may be zero, causing select to
return immediately. If timeout is NULL (no timeout),
select can block indefinitely.
Now from <stdio.h>:
#ifndef NULL
#ifdef __cplusplus
#define NULL 0
#else
#define NULL (void*)0
#endif
#endif
Unless I'm missing something blatently obvious, NULL == 0, and thus this
manpage is nonsensical. "It may be zero, causing select to return
immediately. If timeout is NULL (no timeout), select can block
indefinately." How can it return immediately *and* block indefinately?
I'm confused. I've never actually used select(), as odd as that may seem
to some. Well, not with indefinate or zero timeouts, anyway.
------------------------------
From: Richard Henderson <rth@dot.cygnus.com>
Date: Fri, 12 Sep 1997 20:32:52 -0700 (PDT)
Subject: branch prediction hints (was Re: patch for 2.1.55 pre-1
minix/sysv/affs)
> But supporting hints about which way is the likely branch would be good.
> I'd prefer something like
>
> __builtin_unlikely_if (x) {
> }
>
> which would work fine inside #defines and inline functions etc.
Interestingly, I've discovered here at Cygnus a set of patches
(that needs lots of cleaning up) to do something very like this.
It takes the form:
x = __builtin_expect(some_int_expr, const_int_expr);
if (x) {
}
that is, __builtin_expect infects the rtl associated with the
value it got from some_int_expr, which may then be inspected
by a later conditional. The value of X is predicted to be
the same as const_int_expr.
It does need some amount of backend support to be effective,
and is currently only implemented for i960 and rs6000.
> Also, a "__builtin_unlikely_if()" can be used to move the unlikely code
> away from the likely case, so that it doesn't pollute the icache at all
> (into another ELF segment etc).
That is, of course, the ultimate goal, though this code only deals
with setting branch prediction bits. Due to other, extremely nasty
code generation habits of e.g. exception handling, I may look into
general motion of basic blocks, but probably not soon.
r~
------------------------------
From: Tom Dyas <tdyas@romulus.rutgers.edu>
Date: Fri, 12 Sep 1997 23:40:54 -0400 (EDT)
Subject: Re: how to tell if data is available for a file descriptor
On Fri, 12 Sep 1997, Jason Burrell wrote:
> Unless I'm missing something blatently obvious, NULL == 0, and thus this
> manpage is nonsensical. "It may be zero, causing select to return
> immediately. If timeout is NULL (no timeout), select can block
> indefinately." How can it return immediately *and* block indefinately?
>
> I'm confused. I've never actually used select(), as odd as that may seem
> to some. Well, not with indefinate or zero timeouts, anyway.
If the value of the passed pointer is 0 (a.k.a. NULL), then select() will
block indefinitely. The "zero" refered to in the man page is the value
contained within the fields of a passwd timeval strcuture. Thus, the
pointer would be non-NULL and the fields tv_sec and tv_usec would be 0.
Tom
------------------------------
From: "Jon M. Taylor" <taylorj@ecs.csus.edu>
Date: Fri, 12 Sep 1997 20:58:17 -0700 (PDT)
Subject: Re: Console mapping problems? [I hear about these - I wanna know!]
On Fri, 12 Sep 1997, H. Peter Anvin wrote:
> > I'm not sure what you mean by 'sources' here. Different
> > manufacturers? Different types of video I/O?
>
> Different data sources.
Oh, OK. Yes, this is most definitely an issue, which is why
EvStack (The GGI project's new console subsystem replacement) is based on
a message-passing paradigm similar to what you commonly see with
networking protocols. As long as the subject has come up (hehehe), let me
take this opportunity to expound in more detail upon the wonderfulness
that is EvStack. The following description/lecture is very long, but as
it pertains to what the GGI project feels is a very fundamental revolution
in a very fundamental core component of the Linux kernel, I cannot do it
justice without a detailed explanation.
Also, keep in mind that, while I am a GGI developer and have
played around quite a bit with what is currently available, EvStack is
very much a work in progress and the final authority on its minutiae is
Andreas Beck, founder of the GGI project. If you have any further
questions/suggestions/complaints about EvStack, he is the one to talk to.
EvStack is one of the most innovative ideas I have come across in quite
some time (though perhaps not as much to some on this list with more OS
design experience than myself), and my hat is definitely off to Andy.
With all that in mind, here we go....
There are a lot of similarities between console I/O and network
I/O: both deal with very high bandwidth data streams, both have to handle
data flowing from many different sources to many different destinations
with potentially complex multi-level routing and protocols, both have to
handle many different types of data in a generic, flexible and fast
manner, and both benefit from tight kernel integration due to their
necessarily tight hardware coupling. EvStack is based upon this concept,
which reduces all console I/O handling to the routing and tweaking of
streams of messages and packetized data passing from input sources of
widely varying types to output devices, also of widely varying types.
When you are designing a system for handling as many divergent
types of input and output devices as exist on the whole range of computing
hardware available today (which the GGI has to, because Linux will
eventually run on everything), this type of message passing system is
pretty much a necessity. You simply cannot provide an adequate level of
speed and flexibility with a traditional function-based API - even if you
extend one of those to cover every single I/O device currently in
existence, it'll become a bloated monstrosity, which will become even more
bloated over time as more and more new devices need supporting, AND it
will be changing out from under the developers every day!. It just will
not work. Message passing, on the other hand, is almost infinitely
flexible and extensible. All you have to do to see this is look at any
networking protocol. This was Andy's reasoning behind why EvStack is
designed as it is, and it sure makes sense to me.
I find it difficult to think up a console I/O operation of any
kind that cannot be handled with EvStacks, the _simplest_ of which are the
increases in available console features commonly discussed on
linux-kernel. Serial consoles, multilayer terminal emulations, font
handling, VC tweaking/redirection, code page translation, handling of
bizarre input devices, and of course any imaginable type of graphics
drawing accelerations or other features are *EASILY* handled with
practically infinite flexibility. It's all just a bunch of messages and
data, flowing from a source to a destination, with routing and tweaking
along the way.
Want to run your console output to a braille reader? No problem,
just insert a substack that routes console output to the braille-reader
driver. Want to set up your SpaceOrb 360 joystick to simulate keypresses
so it can be used with any keyboard-using game (Descent is a good example)
without the game having to know anything about the peculiarities of the
joystick? No problem, just insert the appropriate translation substack
between the joystick input driver and the console such that the console
sees keypress events as appropriate. Completely transparent, all of it,
to the kernel devices, userspace console-using apps and other stacks and
substacks.
EvStack is based upon EvPages, fixed-length chunks of data
somewhat analogous to network packets. One consequence of this is that
there need be no difference between EvStacks and their associated EvPages
in kernel and user space! it is all just a bunch of 'packets' of various
types, and as a consequence the kernel-user interface transition ceases to
be nearly the performance hit it once was. Users can insert and remove
their own user-level stacks for their own purposes without affecting
anything outside their own priviledge space, let alone having to recompile
the kernel! The kernel drivers can stay exactly the same, while what is
done with the information they provide is infintely configurable at
runtime in userspace! Another useful feature this kernel/user
transparency makes posible is very aggressive queueing and pipelineing
techniques for message handling on both the kernel and user sides. Fast,
fast, fast.
Users can insert, remove, and tweak the relationships between the
userspace stacks that interpret, massage and route the messages
originating from the kernel drivers/stacks in an unlimited number of ways.
Because of this, the kernel drivers no longer need to be nearly as
intelligent (and large, and slow, and inflexible, and potentially buggy,
and hard to maintain and document), because their communication with
userspace no longer needs to be shoehorned into any one fixed API. The
userspace stacks and libraries that will ride on top of the kernel will
take care of that end of things. The kernel input device drivers just
tell their associated handler stacks what their hardware is doing - no
frills, no interpretation, just the raw unvarnished hardware state - and
that is it. The intelligence associated with taking that device-state
info and actually doing something useful with it is elsewhere.
A great example of how this moving of device-specific intelligence
to userspace is a big win is Mesa. This is a userspace function library
that implements the OpenGL API. When the planned GGI-based Mesa port is
up and running in its final form (it already runs unaccelerated),
userspace code will link to Mesa as normal, but the Mesa library will be
EvStack aware and be able to dynamically load and unload card-specific
userspace stacks that will enable it to communicate with the kernel video
card drivers in highly flexible, optimizable and hardware-specific way.
The base kernel video drivers will blindly send and recieve messages as
described in the previous paragraph, which allows us to fine-tune the
whole communication path from the hardware -> kernel drivers -> kernel
EvStacks -> userspace EvStacks -> Mesa (and back again, as almost all
video drivers will need to send and recieve messages).
The optimal way to set this sort of communications pathway up
varies incredibly across different types of hardware, which I think leads
many GGI skeptics to doubt our ability to place all that mess under kernel
control and still have decent speed and access to card-specific features.
Doubt no more. Now, with the flexibility EvStack gives us, we can
fine-tune the stacks in question to implement this communications path
with MUCH finer-grained level of control and optimizeablility than would
ever have been possible with a traditional function-based kernel API.
The GGI project used to consider kernel graphics as the major
advance that the GGI would provide to Linux, but as the EvStack concept
has developed it has become clear to us that EvStack is the *real*
fundamental advance and that kernel graphics is just one of many
improvements to Linux made possible by EvStack. The Linux console
subsystem is aging and is due for a major overhaul. We have that
overhaul, and it certainly qualifies as "major" |->.
> > > However, when I say people are being too absolutist I mean both ways.
> > > I'm quite happy going with whomever puts out the better solution
> > > (XFree86 or GGI.) I'm just commenting on what I see.
> >
> > It hurts to be labeled an absolutist when we feel that we are
> > simply following established OS design principles.
>
> Well, there are a number of "established OS design principles" -- one
> of them is "don't do it in kernel space unless you absolutely have
> to."
Well, we have to.
> Linux has a problem with people trying to put way too many
> things in kernel space, and putting a brake on that is usually
> necessary.
This is true, but some things just plain belong behind that
kernel wall and hardware banging code is one of them. Besides, if you
read the above EvStack explanation you will see that we should be able to
greatly reduce the size of a lot of the current kernel drivers and move a
lot of their intelligence to userspace. You should be happy!
> Speaking personally; maybe you guys ought to consider making status
> summaries ("this is what we have so far") and post them.
Consider this post a status report.
> I think the
> perception is still pretty widely spread that since you didn't get
> unconditional approval from the start, you went off in a huff.
We just thought that people were getting sick of the endless
flaming and that THAT was damagin our reputation.
> That is, if you care.
We do. Dammit, we are doing what we do for the benefit of
everyone that uses Linux!
Jon
------------------------------
From: linux kernel account <linker@nightshade.z.ml.org>
Date: Fri, 12 Sep 1997 23:07:19 -0400 (EDT)
Subject: Tasklist problems..
A little bit back I was having problems with crond becoming task -9 (on my
system cron is normally pid9).. It seemed to happen when crond was running
updatedb, esp on vfat devices. It looked like it went away with .54..
BUT..
I ran badblocks on some IDE disk (a ~600megger) and the loadavg went
throught the roof.. Also:
Sep 12 23:52:10 limelight kernel: badblocks -8 R current 0 100 70
I ctrl-c ed it.. A second later:
Sep 12 23:52:53 limelight kernel: badblocks 8 R C0106000 0 100 70
Sigh..
------------------------------
From: "Mr. James W. Laferriere Network Engineer" <babydr@nwrain.net>
Date: Fri, 12 Sep 1997 21:39:10 -0700 (PDT)
Subject: Re: /proc/pci design idea
Hello Stehpen,
Please also take a look at
David Howell's Config Manager v023, 12/06/97
http://lucifer.hemmet.s-hem.chalmers.se/~dwh
Which reminds me I haven't heard a peep out of Mr. Howell's
since the v0.23 announcement....
This is a -very- cool way to do this, I beleive that
David Miller said its one of the best methods he had
seen to that time...
On Thu, 11 Sep 1997, Stephen Williams wrote:
> I'm considering taking on the task of moving device identification
> messages for PCI devices into user space. It makes little sense to me
> to keep vendor/device names compiled into the kernel. Makes it ugly for
> those of us who ship PCI boards with linux drivers as modules.
>
> So I'm thinking of turning /proc/pci into the directory /proc/pcibus
> with subdirectories xx (bus number) and yy under that for a device.
>
> i.e. /proc/pcibus/01/40 identifies a specific device on bus 1, dev_fn 0x40.
>
> That file would contain the 256byte configuration space for the device.
> A user-mode program would interpret the bytes to make a pretty display,
> if such a thing is desired. (Such a thing is desired by me:-)
>
> I'm starting with a 2.1.55 kernel and I can probably have it working in a
> few days.
> --
> Steve Williams
> steve@icarus.com
> steve@picturel.com
>
> "The woods are lovely, dark and deep. But I have promises to keep,
> And lines to code before I sleep, And lines to code before I sleep."
Tia, JimL
+-----------------------------------------------------------------------+
| James W. Laferriere - Network Engineer - babydr@nwrain.net |
| System Techniques - 25416 - 22nd S. - Kent, WA 98032 |
| Give me VMS -or- Give me Linux -but- only on AXP |
+-----------------------------------------------------------------------+
|-> Linux-Vax Port, Now in Progress !YAY! there's Progress To Report <-|
|-> Please See http://ucnet.canberra.edu.au/~mikal/vaxlinux/home.html <-|
|-> Maintainer: Michael Still mikal@blitzen.canberra.edu.au <-|
+-----------------------------------------------------------------------+
, JimL
+-----------------------------------------------------------------------+
| James W. Laferriere - Network Engineer - babydr@nwrain.net |
| System Techniques - 25416 - 22nd S. - Kent, WA 98032 |
| Give me VMS -or- Give me Linux -but- only on AXP |
+-----------------------------------------------------------------------+
|-> Linux-Vax Port, Now in Progress YAY there's Progress To Report <-|
|-> Please See http://ucnet.canberra.edu.au/~mikal/vaxlinux/home.html <-|
|-> Maintainer: Michael Still mikal@blitzen.canberra.edu.au <-|
+-----------------------------------------------------------------------+
My System & Libraries & Programs status, At this time are:
-----------------------------------------------------------
AMD-5k86-P90 , 64MB Main memory , 512K L2 Cache.
no-name M.B. , pci & isa slots , Triton chipset
pci1-SVGA-gd5446 , pci2-Asus-SC200 , pci3-Asus-SC200
pci4-Eepro100b ,
-----------------------------------------------------------
Kernel version: Linux-2.0.30
Patches applied:
Donald Becker eepro100.c, v0.32a, 08/04/97
Gerard Roudier ncr53c8xx.c, v2.3c, 04/07/97
David Miller 2.0.31-prepatch v2, 29/05/97
Dr. Wern Fink Perfect-buffer, v1, 09/07/97
Jen Maurer's pci.h patch for 2.0.30 06/06/97
-----------------------------------------------------------
Gcc v. 2.7.2.1 ; binutils-2.7.0.9 ; sysvinit-2.62
ld.so.1.8.10 ; libc.so.5.4.23 ; C++ Lib-27.2.1
libg++.so.27.1.4 ;
proc-ps 1.12 ; net-tools 1.32a ; mount-2.6d
Modules-2.1.23 ; loadkeys 0.89 ; yacc-1.8
Flex 2.5.4 ; e2fsprogs-1.10 ; Sh-utils-1.12
-----------------------------------------------------------
------------------------------
End of linux-kernel-digest V1 #1152
***********************************
To subscribe to linux-kernel-digest, send the command:
subscribe linux-kernel-digest
in the body of a message to "Majordomo@Majordomo.vger.rutgers.edu". If you
want
to subscribe something other than the account the mail is coming from,
such as a local redistribution list, then append that address to the
"subscribe" command; for example, to subscribe "local-linux-kernel":
subscribe linux-kernel-digest local-linux-kernel@your.domain.net
A non-digest (direct mail) version of this list is also available; to
subscribe to that instead, replace all instances of "linux-kernel-digest"
in the commands above with "linux-kernel".