On Wed, 18 Oct 2000, Arjan van de Ven wrote:
> In article <[EMAIL PROTECTED]> you wrote:
>
> > It should, unless you want to open any files in the thread itself.
>
> Oh damn. kHTTPd does need to open files later on..
>
> Reading the code to exit_files() suggests I actually need put_file
On Wed, 18 Oct 2000, Jeff Garzik wrote:
> Alexander Viro wrote:
> > On Wed, 18 Oct 2000, Alessandro Rubini wrote:
> > > > shouldn't this be exit_files() ?
>
> > > Yes, definitely.
> > > Arjan already replied (privately) to say the same.
>
&
On Wed, 18 Oct 2000, Alessandro Rubini wrote:
>
> > put_files_struct() is a destructor, so it won't help here. The following
> > patch may be of use [...] It's "create an empty
> > files_struct and replace the task->files with it" - thing we can't do via
> > clone() and may want to (khttpd doe
On 20 Oct 2000, Trond Myklebust wrote:
> Under NFS the problem is that pages can (and *should*) be invalidated
> despite there being pending write backs. The server can trigger the
> need for a cache invalidation at any time.
OK, so what should happen if user does mmap() on NFS file, dirties t
On Fri, 20 Oct 2000, Roger Larsson wrote:
> Is it legal/good practice to unmap the file after closing it?
Yes.
> (Since the sharing needs the fd to mmap it)
It doesn't. Mapping needs struct file * and it doesn't care about
fd. mmap() takes a reference to struct file by fd you've passed and af
On 20 Oct 2000, Trond Myklebust wrote:
> > " " == Russell King <[EMAIL PROTECTED]> writes:
>
> > invalidate_inode_pages nfs_zap_caches nfs_lock fcntl_setlk
> > do_fcntl sys_fcntl
>
> > So I guess that NFS locking is really bad if the region is
> > mmapped!
>
> Yep, bu
On Fri, 20 Oct 2000, Trond Myklebust wrote:
> For the general case of the page cache I think we can keep them quite
> simple:
>
> + We do in any case want to drop all pages that are unreferenced. (The
> reason for flushing may be that the file size has changed.)
>
> + For pages that are refer
On Thu, 19 Oct 2000, Marty Fouts wrote:
> > -Original Message-
> > From: Matti Aarnio [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, October 19, 2000 1:26 PM
> > To: [EMAIL PROTECTED]
> > Subject: [ADMIN] some list related topics ..
>
> [snip]
>
> >
> > 3) some ISP systems yield 50
On Thu, 19 Oct 2000, Linus Torvalds wrote:
> You'd have to do something like
>
> LockPage(page); /* Nobody gets to write to this page (except
>through mmaps, ugh) */
> gather_all_mmap_users(page);/* THIS is the nasty one */
Wait a second. invalidate_inode_page
On Fri, 20 Oct 2000, Matt Peterson wrote:
> cvs-1.10.8/vms/rcmd.c:64:rs = bind(s, (struct sockaddr *)&local_isa,
^^^
> sizeof(local_isa));
> cvs-1.10.8/vms/rcmd.c:79:rs = bind(s, (struct sockaddr *)&local_isa,
^^^
> sizeof(local_isa));
>
> The cvs code does c
On Mon, 23 Oct 2000, Linus Torvalds wrote:
> Al, any ideas? I have this feeling that the simplest fix is just to leave
> the race open, and make truncate_complete_page() just leave such a "racy"
> page in the page cache. It will still race, and the invalid page will
> still exist, but the end res
On Mon, 23 Oct 2000, Linus Torvalds wrote:
> On Mon, 23 Oct 2000, Alexander Viro wrote:
>
> > On Mon, 23 Oct 2000, Linus Torvalds wrote:
> >
> > > Al, any ideas? I have this feeling that the simplest fix is just to leave
> > > the race open, and make trunca
On Mon, 23 Oct 2000, Linus Torvalds wrote:
> On Mon, 23 Oct 2000, Alexander Viro wrote:
> >
> > That's fine, but I'm afraid that we'll need a bit more than that. A couple of
> > obvious ones:
> > * filemap_nopage() needs the second check for ->
On Mon, 23 Oct 2000, Linus Torvalds wrote:
> Also, the fact that Petr didn't see anything trigger in nopage() makes me
> nervous again. Even if the problem happened during read-ahead, it should
> have gotten into the address space only through nopage. Maybe there is
> some vma that isn't added
Oh, crap... Who introduced ->i_mmap_shared/->i_mmap separation and what
analysis had been done? Petr, can you reproduce the problem on -test7?
Unfortunately, clean test would take the backport of ext2 changes
(truncate-related, happened around the same time), but IIRC -test7 was
relatively stabl
On Mon, 23 Oct 2000, Linus Torvalds wrote:
>
>
> On Mon, 23 Oct 2000, Alexander Viro wrote:
> >
> > Oh, crap... Who introduced ->i_mmap_shared/->i_mmap separation and what
> > analysis had been done? Petr, can you reproduce the problem on -test7?
>
&g
On Mon, 23 Oct 2000, Jordan Mendelson wrote:
> What you describe is exactly what the /dev/poll interface patch from the
> Linux scalability project does.
>
> It creates a special device which you can open up and write
> add/remove/modify entries you wish to be notified of using the standard
>
On Mon, 23 Oct 2000, Linus Torvalds wrote:
> Note that if there really are only 9 "nopage" routines, then it is a lot
> easier to just add the single "SetPageUptodate(page)" into those 9
> routines, and thus let the VM know of the race.
Works for me. And yes, the list of ->nopage instances tha
On Tue, 24 Oct 2000, Petr Vandrovec wrote:
> On 23 Oct 00 at 23:05, Alexander Viro wrote:
>
> > Oh, crap... Who introduced ->i_mmap_shared/->i_mmap separation and what
> > analysis had been done? Petr, can you reproduce the problem on -test7?
> > Unfortunat
In generic_file_readahead():
unsigned long end_index = inode->i_size >> PAGE_CACHE_SHIFT;
unsigned long index = page->index;
...
max_ahead = 0;
...
raend = index;
if (raend < end_index)
On Wed, 25 Oct 2000, Linus Torvalds wrote:
>
>
> On Wed, 25 Oct 2000, Rik van Riel wrote:
> >
> > OTOH, block-dev readahead makes sense for filesystems where
> > the packing locality is close to the access pattern BUT NOT
> > close to anything the page cache would recognise as being
> > clos
On Wed, 25 Oct 2000, Rik van Riel wrote:
> Anyway, below is a patch that implements Al Viro's
> readahead fix and one small readahead adjustment
> that seems to make sense ...
Rik, doesn't said fix need propagation into your adjustment?
-
To unsubscribe from this list: send the line "unsubscr
On Wed, 25 Oct 2000, Alexander Viro wrote:
> I can do the proof-of-concept patch (below 10Kb, ext2 + generic code, with
> the need to repeat the fs-specific parts for other filesystems) in an
> hour. Clearance?
OK, it didn't take an hour. Warning: completely untested, needs
(tr
On Wed, 25 Oct 2000, Jeff V. Merkey wrote:
> Al,
>
> Thanks. I'll print this one out and post it on the wall for tonight's
> debugging session.
[snip]
> > (e.g. generic_commit_write have to mess with i_size value to update the
^^^
Ugh. s/have/doesn't have/, i
On Wed, 25 Oct 2000, Jeff V. Merkey wrote:
> Alexander Viro wrote:
> >
> > On Wed, 25 Oct 2000, Jeff V. Merkey wrote:
> >
> > > Al,
> > >
> > > Thanks. I'll print this one out and post it on the wall for tonight's
> > > de
On Wed, 25 Oct 2000, Jeff V. Merkey wrote:
> > > :%s/have/doesn't have/gc
> >
> > ??? Why the hell do you want a global replacement?
>
> not global replace, global CONFIRM. Just in case the
Ugh. If you want to be pedantic that's G1:/have/s//doesn't &^M
for you.
-
To unsubscribe from this
On Fri, 20 Oct 2000, Trond Myklebust wrote:
> > " " == David S Miller <[EMAIL PROTECTED]> writes:
>
> > Actually, judging by the trace you provided Russell, I'd say
> > this is some peculiarity with NFS silly rename handling, and
> > it'd be best to look for the bug in that
On Thu, 26 Oct 2000, Linus Torvalds wrote:
> The alternative is to have an entirely different approach, where the page
> cache itself only knows about the maximum page (in which case your current
> "last_page" calculation is right on), and then anybody who needs to know
> about partial pages ne
On Sun, 29 Oct 2000, Mohammad A. Haque wrote:
> I JUST got the same oops. But daylight savings happened 9 or so hours
> ago here.
Known problem, fix being tested. Basically, it's the same as mmap/truncate
races, with do_generic_file_read() in place of filemap_nopage(). I wonder
what made it vi
On Sun, 29 Oct 2000, Linus Torvalds wrote:
> approach for 2.4.x where we just re-test against the file size in multiple
> places where this can happen - but it would be nicer to handle this more
> cleanly.
One possible way is to access page->mapping _only_ under the page lock
and in cases when
On Sun, 29 Oct 2000, Alan Cox wrote:
> > I would expect problems with truncate, mmap, rename, POSIX locks, fasync,
> > ptrace and mount go unnoticed for _long_. Ditto for parts of procfs
>
> Well the ptrace one still has mysteriously breaks usermode linux against it
> on my list here. Was that
On Mon, 30 Oct 2000, Linus Torvalds wrote:
>
> Ok, this one contains at least a preliminary fix for the problem with
> truncate together with a concurrent page access - the bug that causes
> oopses in block_read_full_page() and filemap_nopage().
>
> This is a fairly minimal fix, and I'll stil
On Mon, 30 Oct 2000, Linus Torvalds wrote:
> How about just changing ->sync_page() semantics to own the page lock? That
> sound slike the right thing anyway, no?
It would kill the ->sync_page(), but yes, _that_ might be the right thing ;-)
> I didn't actually miss it, I just looked at the use
On Mon, 30 Oct 2000, Alexander Viro wrote:
>
>
> On Mon, 30 Oct 2000, Linus Torvalds wrote:
>
> > How about just changing ->sync_page() semantics to own the page lock? That
> > sound slike the right thing anyway, no?
>
> It would kill the ->sync_page()
On Mon, 30 Oct 2000, Linus Torvalds wrote:
> Ok, sync_page() looks like a broken design, but I suspect that for
> expediency the simplest fix is to just make the NFS sync_page() (re-)check
> for "mapping == NULL", and let it be at that. Avoid the NULL pointer
> dereference (very small window al
Bunch of sysctl bugs:
* use of proc_dostring with ->strategy==NULL instead of systcl_string.
* use of sysctl_intvec with NULL ->extra1 and ->extra2 (harmless, but silly).
Patch follows. Please, apply.
Cheers,
procfs provides.
>
> You can get the quick hack from here (this patch is against 2.4.0-test10):
>
> http://thor.sbay.org/~dave/taskfs_and_kernfs.diff.gz
>
> I've tested the two file systems on the user-mode-linux kernel. :-)
> They both seem to work as expected, even when
On Sun, 5 Nov 2000, Dave Zarzycki wrote:
> On Sun, 5 Nov 2000, Alexander Viro wrote:
>
> > However, kernfs is _not_ procfs \setminus procfs-proper. It's our current
> > /proc/sys.
>
> Okay. I didn't realize that's what you had in mind when you wrote
&
On Sun, 5 Nov 2000, Anonymous wrote:
> Does anyone know where to find a gui for gcc or g++ or any compiler for a
> KDE shell?
Yes.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/
On Mon, 6 Nov 2000, Jeff Garzik wrote:
> The address_space::writepage callback is called from try_to_swap_out()
> path, and also from the filemap_sync_pte() path. There appears to be no
> way to tell the difference between the two callers. This is not good
> because the semantics are very dif
On Thu, 9 Nov 2000, Michael Rothwell wrote:
> Same as before -- freedom and low cost. The primary advantae of Linux
> over other OSes is the GPL.
Now, that's more than slightly insulting...
The problem with the hooks et.al. is very simple - they promote every
bloody implementation detail to
On Thu, 9 Nov 2000, Michael Rothwell wrote:
> Alexander Viro wrote:
> >
> > On Thu, 9 Nov 2000, Michael Rothwell wrote:
> >
> > > Same as before -- freedom and low cost. The primary advantae of Linux
> > > over other OSes is the GPL.
> >
On 9 Nov 2000, Mike Coleman wrote:
> Alexander Viro <[EMAIL PROTECTED]> writes:
> > RMS had repeatedly demonstrated what he's worth as a designer
> > and programmer. Way below zero. You may like or dislike his ideology,
> > but when it comes to techni
On Fri, 10 Nov 2000 [EMAIL PROTECTED] wrote:
>
>
>
> > The problem with the hooks et.al. is very simple - they promote every
> > bloody implementation detail to exposed API.
>
> Surely not, having the kernel source does that. The alternative to the hook
> is embed a patch in the kernel
On Fri, 10 Nov 2000, Michael Rothwell wrote:
> > Sorry. You don't "embed" the patch. You either get it accepted or not.
> > Or you fork the tree and then it's officially None Of My Problems(tm).
>
> Sounds like a good idea.
It's not a good idea, it's an obvious fact. Oh, you mean forking the
On Fri, 10 Nov 2000, Chris Swiedler wrote:
> Here's an updated version of the "oom_nice" patch. It allows a sysadmin to
> set the "oom niceness" for processes, either by PID or by process name. The
> oom niceness value factors into the badness() function called by Rik's
> OOM killer. Negative v
% find . -type f | xargs grep -nw CTL_ANY
./kernel/sysctl.c:370: if (n == table->ctl_name || table->ctl_name ==
CTL_ANY) {
./include/linux/sysctl.h:47:#define CTL_ANY -1 /* Matches any name */
And no, there is no ctl_table that would be getting explicit -1 as ->ctl_nam
* thread_saved_pc() on x86 returns (thread->esp)[3]. Bogus, since the
third word from the stack top has absolutely nothing to return address of
any kind. Correct value: (thread->esp)[0][1] - ebp is on top of the stack
and the rest is obvious. Current code gives completely bogus addresses -
Couple of places missed in Jeff's patch:
diff -urN rc11-2/fs/ncpfs/mmap.c rc11-2-kmap/fs/ncpfs/mmap.c
--- rc11-2/fs/ncpfs/mmap.c Sun Aug 6 13:43:18 2000
+++ rc11-2-kmap/fs/ncpfs/mmap.c Fri Nov 10 16:31:01 2000
@@ -37,7 +37,7 @@
struct dentry *dentry = file->f_dentry;
On Fri, 10 Nov 2000, Jeff V. Merkey wrote:
>
> Then perhaps qmail's time has finally come If sendmail cannot run
> on a machine with minimal background loading from a dozen or so FTP
> clients downloading files, it's clearly sick. BTW. I have another box
> running qmail, and it doesn't
On Sat, 11 Nov 2000, Linus Torvalds wrote:
> On Fri, 10 Nov 2000, Alexander Viro wrote:
> > diff -urN rc11-2/include/asm-i386/processor.h
>rc11-2-show_task/include/asm-i386/processor.h
> > --- rc11-2/include/asm-i386/processor.h Fri Nov 10 09:14:04 2000
> > +++
On Sat, 11 Nov 2000, Alexander Viro wrote:
> I would probably turn it into
> unsigned long *ebp = *((unsigned long **)t->esp);
ebp++; /* We want return address, not the previous frame pointer */
> /* Bits 0,1 and 13..31 must be shared with the stack base *
On Thu, 7 Dec 2000, Andries Brouwer wrote:
> On Thu, Dec 07, 2000 at 10:24:31AM -0500, Alexander Viro wrote:
>
> > Al, currently walking through the /usr/share/man/man2 and swearing silently...
>
> Swearing? At the POSIX decisions or at the man page quality?
Mostly at t
s, it prevents the issue.
>
> > Please note that the patch circumvents the problem more than it fixes it.
> > The true fix would invalidate the mappings, but I don't know how to do it.
>
> I don't know either. What does Alexander Viro say to all of this?
That invalida
On Fri, 8 Dec 2000 [EMAIL PROTECTED] wrote:
> > BTW, if you still have 1.7, 1.10, 1.13 and 1.14...
>
> See ftp://ftp.cwi.nl/pub/aeb/manpages/ (will soon disappear again).
Got them, thanks.
> > BTW, could we finally lose mpx(2)?
>
> Maybe we lost it - I find sys_mpx only in a comment in arch
I'm doing some massive grepping (basically, audit of page locking),
but nothing relevant so far. There was some catch (aside of documenting
the thing and finding several completely unrelated buglets):
* ramfs_writepage() doesn't UnlockPage(). Deadlock.
* udf_adinicb_writepa
Folks, see if the following patch helps. AFAICS it closes a pretty real
race - we could call block_write_full_page() for a page that has sync
IO in progress and blindly change ->b_end_io callbacks on the bh with
pending requests. With a little bit of bad luck they would complete before
we got to l
On Fri, 8 Dec 2000, Linus Torvalds wrote:
> It's really only __block_prepare_write() that can mark the buffers for
> sync writes, and even that case is fairly bogus: it really only wants to
> mark the non-upto-date buffers that it wants to _read_ for sync IO, it
> just "knows" that it is ok to
On Fri, 8 Dec 2000, Linus Torvalds wrote:
>
>
> On Fri, 8 Dec 2000, Alexander Viro wrote:
> >
> > Erm... So you want to make ->commit_write() page-unlocking? Fine with me,
> > but that will make for somewhat bigger patch. Hey, _you_ are in position
> > to
On Fri, 8 Dec 2000, Linus Torvalds wrote:
> Looking more at this issue, I suspect that the easiest pretty solution
> that everybody can probably agree is reasonable is to either pass down the
> end-of-io callback to ll_rw_block as you suggested, or, preferably by just
> forcing the _caller_ to
On Sat, 9 Dec 2000, Mohammad A. Haque wrote:
> It was just an example. Basically, you'd be able to do in with just
> about any language that has ORBit bindings.
Yeah... "Infinitely extendable API" and all such. Roughly translated
as "we can't live without API bloat". Frankly, judging by the GN
On Sat, 9 Dec 2000, Linus Torvalds wrote:
> This is a preliminary patch that I have not compiled and probably breaks,
> but you get the idea. I'm going to sleep, to survive another night with
> three small kids.
>
> If somebody wants to run with this, please try it out, but realize that
> it's
On Sat, 9 Dec 2000, Alan Cox wrote:
> > Yeah... "Infinitely extendable API" and all such. Roughly translated
> > as "we can't live without API bloat". Frankly, judging by the GNOME
> > codebase people who designed the thing
On Sat, 9 Dec 2000, Andries Brouwer wrote:
> On Sat, Dec 09, 2000 at 05:40:47AM -0500, Alexander Viro wrote:
>
> > > @@ -1210,7 +1204,6 @@
> > [breada()]
> > Umm... why do we keep it, in the first place? AFAICS the only
> > in-tree user is hpfs_map_sec
I wrote:
> Yeah... "Infinitely extendable API" and all such. Roughly translated
> as "we can't live without API bloat". Frankly, judging by the GNOME
> codebase people who designed the thing are culturally incompatible with
> UNIX.
Hrrm. After rereading... I suspect that I wasn't clear en
On Sat, 9 Dec 2000, Alan Cox wrote:
> > > From what I've seen in GNOME it's mostly about avoiding pipes
> > > religiously and putting everything and a kitchen sink into the same
> > > process. I'm not saying that it has no valid uses, but it definitely
> > > had contributed to the bloat in cas
On Sun, 10 Dec 2000, Miloslav Trmac wrote:
> Hi,
> vmtruncate () in test11 doesn't clear ends of partial pages. Patch is attached
It doesn't and it shouldn't. That's done in ->truncate(). Check ext2_truncate()
for example.
-
To unsubscribe from this list: send the line "unsubscribe linux-kern
On Mon, 11 Dec 2000, Martin Dalecki wrote:
> Please don't put KDE into the same bunch as gnome or
> windows. KDE is in fact *well designed*! In esp. 2.0
'Tis funny, you know, because ISTR that the bloody thing
got the same problems with the program sizes, API bloat and lack of
orthogonality.
On Mon, 11 Dec 2000, Dietmar Kling wrote:
> I do not understand this
> "i saw it - yuck! - and now i want to kill it "
s/want to kill it/do not want to touch it/
> point of view.
> As I tried to point out. Things evolve. And
> the evolution has the right do things wrong.
> Next evolution ste
On Mon, 11 Dec 2000, Dietmar Kling wrote:
> > You do realize what "evolution" means? I'm not talking about the bugs
> > in implementation. I'm talking about botched design. _That_ never gets
> > fixed. Show me one example when that would happen and I might consider
> > taking such possibility s
On Wed, 13 Dec 2000, Andreas Dilger wrote:
> Hello,
> while looking at the COMPAT flag patches I made, I noticed the following
> in the ext2/ext3 code. I believe that this bug is fixed in 2.4, but it
> also needs to be fixed in 2.2. Basically, we are checking for an ext2
> large file, which w
On 13 Dec 2000, Henrik [ISO-8859-1] Størner wrote:
> Just to add a "me too" on this. I didn't report when I saw it last week,
> because I was uncertain of exactly what might have caused it - I was
> booting several different kernels at the time, including one from a
> rescue disk (I was trying
On Thu, 14 Dec 2000, Alan Cox wrote:
> > Don't worry about kORBit. Like most open source projects, it will simply
> > die out after a while, because people don't find it interesting and there
> > is really no place for it. If it becomes useful, mature, and refined,
> > however, it could be a
On Wed, 13 Dec 2000, Chris Lattner wrote:
> Err... how about this: Give me two or three kORBit syscalls and I can get
> rid of all the other 100+ syscalls! :)
Like it ioctl() does it? Number of entry points is _not_ an issue. Diversity
of the API is. Technically, kernel has 1 (_o_n_e_) entr
On Wed, 13 Dec 2000, Chris Lattner wrote:
> CORBA, today, gives us superior interoperability (through IIOP), with
> extensibility for the future. As Alexander Viro mentions, 9P may be a
> better protocol for local communications...
Local? Funny. It lives atop of TCP or IL q
On Wed, 13 Dec 2000, Chris Lattner wrote:
> > > Err... how about this: Give me two or three kORBit syscalls and I can get
> > > rid of all the other 100+ syscalls! :)
>
> > Like it ioctl() does it? Number of entry points is _not_ an issue. Diversity
> > of the API is. Technically, kernel ha
On Wed, 13 Dec 2000, Chris Lattner wrote:
>
> /me trims down CC list...
>
> > Local? Funny. It lives atop of TCP or IL quite fine. What's
> > even funnier, I can use it to export /proc from CPU server to workstation
> > and use _that_ for remote debugging. Ditto for window system. Ditto f
On Wed, 13 Dec 2000, Chris Lattner wrote:
> > plan-9.bell-labs.com/sys/man/
Arrgh. s/plan-9/plan9/. My apologies.
> Err... yeah, so you're effectively mapping UNIX/POSIX across 9P. That's
> not very creative, and you could do the same thing with CORBA. I ask
> again, "How much development i
On Wed, 13 Dec 2000, Chris Lattner wrote:
>
> > > either. Oops, wasn't interoperability an important part of the Linux
> > > kernel design? Didn't we want to use and follow and define _real_
> > > standards?
> > Erm... 9P stub exists for Linux. It exists for FreeBSD. I suspect that
> > it e
On Wed, 13 Dec 2000, Chip Salzenberg wrote:
> According to Alexander Viro:
> > 9P is quite simple and unlike CORBA it had been designed for taking
> > kernel stuff to userland. Besides, authors definitely understand
> > UNIX...
>
> As nice as 9P is, it'll nee
On Wed, 13 Dec 2000, Chris Lattner wrote:
> Which is exactly why it doesn't work well for many applications. The
> problem is this: how do you get from a byte stream to a structured data
> stream? There are many answers:
>
> 1. Keep your data structures so simple, that it's obvious. Not a g
On Wed, 13 Dec 2000, Chip Salzenberg wrote:
> According to Alexander Viro:
> > On Wed, 13 Dec 2000, Chip Salzenberg wrote:
> > > According to Alexander Viro:
> > > > 9P is quite simple and unlike CORBA it had been designed for taking
> > > > k
On Wed, 13 Dec 2000, Chris Lattner wrote:
> > > Okay, so there are _stubs_ for these platforms. How many languages are
> > > there bindings for?
> > Grr... Let's define the terms, OK? What is available: kernel code that
> > represents the client side of RPC as a filesystem. Userland clients do
On Wed, 13 Dec 2000, Chip Salzenberg wrote:
> As long as names are to be created, or at least understood, by humans,
> there will be some limit on *usable* length. In my experience, 255 is
> above that limit, but 30 is below it. And I cut my teeth on a system
> that had exactly that length li
On Wed, 13 Dec 2000, Chris Lattner wrote:
> > OK, now I'm completely confused.
> > * which complex data structures do you want to export from the kernel
> > in non-opaque way?
> > * which of those structures are guaranteed to remain unchanged?
> > * if you have userland-to-userlan
On Thu, 14 Dec 2000, Chris Lattner wrote:
> > Oh, great. So we don't have to care about formatting changes. We just
> > have to care about the data changes. IOW, we are shielded from the
> > results of changes that should never happen in the first place. And the
> > benefit being...?
>
> What
On Thu, 14 Dec 2000, josef [iso-8859-1] höök wrote:
> Chip Salzenberg wrote:
>
> > According to Alexander Viro:
> > > 9P is quite simple and unlike CORBA it had been designed for taking
> > > kernel stuff to userland. Besides, authors definitely understand
>
On Thu, 14 Dec 2000, Chris Lattner wrote:
> > Yes, I did. What I don't understand is how kernel mechanism for marshalling
> > would make your life easier wrt changes.
>
> I gave a very simple example of how an interface could be designed and
> then later extended without breaking any user spac
On Thu, 14 Dec 2000, LA Walsh wrote:
> So I ran into a snag with that scenario. Let's suppose we have
> a module developer or a company developing a driver in their own
> /home/nvidia/video/drivers/newcard directory. Now they need to include
> kernel
> development files and are used to just d
On 15 Dec 2000, Miquel van Smoorenburg wrote:
> In article <[EMAIL PROTECTED]>,
> LA Walsh <[EMAIL PROTECTED]> wrote:
> >Which works because in a normal compile environment they have /usr/include
> >in their include path and /usr/include/linux points to the directory
> >under /usr/src/linux/inc
On Fri, 15 Dec 2000, Alan Cox wrote:
> > >Which works because in a normal compile environment they have /usr/include
> > >in their include path and /usr/include/linux points to the directory
> > >under /usr/src/linux/include.
> >
> > No, that a redhat-ism.
>
> Umm, its a most people except De
On Thu, 14 Dec 2000, David Riley wrote:
> Alexander Viro wrote:
> >
> > Actually, I suspect that quite a few of us had done that since long -
> > IIRC I've got burned on 1.2/1.3 and decided that I had enough. Bugger if I
> > remember what exactly it
On Thu, 14 Dec 2000, Linus Torvalds wrote:
> Good point.
>
> This actually looks fairly nasty to fix. The obvious fix would be to not
> put such buffers on the dirty list at all, and instead rely on the VM
> layer calling "writepage()" when it wants to push out the pages.
> That would be the
On Fri, 15 Dec 2000, Linus Torvalds wrote:
> I really dropped it because I was getting too many patches, and I don't
> realistically think it's a 2.4.0 issue (neither do you, I bet), so I
> decided that it's not worth it.
Umm... Linus, how about a bunch of fixes I've sent to you several times
On Fri, 15 Dec 2000, Linus Torvalds wrote:
> Please instead do the same thing /dev/tty does, namely a sane interface
> that shows it as a symlink in /proc (or even in /dev)
There you go... (/proc/tty/console -> /dev/tty; may very well
be dangling, but then you have a current VC even if your /
On Sat, 16 Dec 2000, Miquel van Smoorenburg wrote:
> There is currently no way to find out with what device /dev/console
> is associated.
>
> Why is that needed? For example, I wrote a program 'bootlogd' that opens
> /dev/console and a pty pair, uses TIOCCONS to redirect console
> messages to
On Sat, 16 Dec 2000, Miquel van Smoorenburg wrote:
> According to Alexander Viro:
> > OK, I can see the point of finding out where the console is redirected
> > to. How about the following:
> >
> > /proc/sys/vc -> /dev/tty
> > /proc/sys/console -&g
On Sun, 17 Dec 2000, Jorg de Jong wrote:
> > >On 13 Dec 2000, Henrik [ISO-8859-1] Størner wrote:
> > >
> > >> Just to add a "me too" on this. I didn't report when I saw it last week,
>
> I'd like to second that. ME TOO !
> Since I switched to 2.4.0.test12 I again have the innd bug.
> ( well at
On Mon, 18 Dec 2000, Neil Brown wrote:
> On Monday December 18, [EMAIL PROTECTED] wrote:
> > > " " == M H VanLeeuwen <[EMAIL PROTECTED]> writes:
> >
> > > Trond, Neil I don't know if this is a loopback bug or an NFS
> > > bug but since nfs_fs.h was implicated so I thought one of
On Mon, 18 Dec 2000, Alan Cox wrote:
> o Fix leak in link() syscall (Al Viro)
^^^
Originally - by Christopher Yeoh.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a m
401 - 500 of 969 matches
Mail list logo
