[EMAIL PROTECTED] wrote:
>
> OK - everybody back from San Jose - pity I couldnt come -
> and it is no longer April 1st, so we can continue quarreling
> a little.
>
> Interesting that where I had divided stuff in the trivial part,
> the interesting part and the lot-of-work part we already start
>
Alan Cox wrote:
>
> > So change them as well for a new distribution. What's there problem.
> > There isn't anything out there you can't do by hand.
> > Fortunately so!
>
> So users cannot go back and forward between new and old kernels. Very good.
> Try explaining that to serious production -use
Alan Cox wrote:
>
> > If anything I'm a *SERIOUS* production user. And I wouldn't allow
> > *ANYBODY* here to run am explicitly tagged as developement kernel
> > here anyway in an production enviornment. That's what releases are for
> > damn.
> > Or do you think that Linux should still preserve D
> One thing I certainly miss: DevFS is not mandatory (yet).
That's "only" due to the fact that DevFS is an insanely racy and
instable
piece of CRAP. I'm unhappy it's there anyway...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTEC
Hello!
The attached patch remove the get_hardblock_size() function entierly
from the kernel. This is due to the fact that this function is
compleatly
unneccessary due to the existance of get_hardsect_size(), which got
introduced to properly encapsulate acesses to the hardsec_size[].
As a side eff
Jens Axboe wrote:
>
> On Sat, Apr 21 2001, Ed Tomlinson wrote:
> > Hi,
> >
> > building a kernel with 2.4.3-ac11 and lvm beta7 + vfs_locking_patch-2.4.2 yields:
> >
> > oscar# depmod -ae 2.4.3-ac11
> > depmod: *** Unresolved symbols in
>/lib/modules/2.4.3-ac11/kernel/drivers/md/lvm-mod.o
> > dep
Jeff Chua wrote:
>
> On Mon, 23 Apr 2001, Martin Dalecki wrote:
>
> > > > depmod: *** Unresolved symbols in
>/lib/modules/2.4.3-ac11/kernel/drivers/md/lvm-mod.o
>
> try this (after you have applied the patch for lvm 0.9.1_beta7) ...
>
> Jeff
> [[E
"Dupuis, Don" wrote:
>
> I have already sent a patch to Alan and Linus on this issue. Linus has
> never responed and Alan said he would look into it in the middle of April.
> Nothing is new at this point
>
> -Original Message-
> From: PhiloVivero [mailto:[EMAIL PROTECTED]]
> Sent: Sunda
Tim Jansen wrote:
>
> The Linux Device Registry (devreg) is a kernel patch that adds a device
> database in XML format to the /proc filesystem. It collects all information
OH SHIT!! ^^^
Why don't you just add postscript output to /proc?
> about the system's physical devices, creates pers
Tim Jansen wrote:
>
> On Tuesday 24 April 2001 11:40, Martin Dalecki wrote:
> > Tim Jansen wrote:
> > > The Linux Device Registry (devreg) is a kernel patch that adds a device
> > > database in XML format to the /proc filesystem. It collects all
> > OH SHIT!!
Peter Samuelson wrote:
>
> [BERECZ Szabolcs]
> > Here is a new syscall. With this you can change the owner of a running
> > procces.
>
> > + if (current->euid)
> > + return -EPERM;
>
> Use capable().
>
> > + p = find_task_by_pid(pid);
> > + p->fsuid = p->euid =
Just a small trivial obviously correct update...
diff -ur linux/include/linux/pci_ids.h linux-mega/include/linux/pci_ids.h
--- linux/include/linux/pci_ids.h Tue Nov 21 16:31:52 2000
+++ linux-mega/include/linux/pci_ids.h Tue Nov 21 18:54:58 2000
@@ -257,6 +257,11 @@
#define PCI_VENDOR_ID_
Linus Torvalds wrote:
>
> On Tue, 5 Sep 2000, Alexander Viro wrote:
> > >
> > > What would be acceptable is something that understands C, and that can be
> > > used to follow these things. Like "tags".
> >
> > I don't like hungarian notation too, but tags is out of question,
> > unfortunate
Alexander Viro wrote:
>
> On Wed, 6 Sep 2000, Martin Dalecki wrote:
>
> > There is some facility allowing to implement this kind of things
> > in the C++ part of the most recent EGCS version which makes implementing
> > such things "relatively" easy - ba
1. This function is only used in the poorly maintained ftape driver.
The usage there isn't appriopriate for modern kernels.
2. This function acts only on the sig set of the current process, so
the first parameter should be just a porinter to current, instead of
currgen->sigset.
So it s
Alexander Viro wrote:
>
> On Wed, 6 Sep 2000, Martin Dalecki wrote:
>
> > Easy - the same way you do for cross compilation. Basically just:
> >
> > export CC=g++ --some-magic-long-option-i-dont-remember; make
>
> ... and you still have only a subset of t
Alan Cox wrote:
>
> > 1. This function is only used in the poorly maintained ftape driver.
> >The usage there isn't appriopriate for modern kernels.
>
> The ftape driver isnt exactly poorly maintained. Its just not integrated into
> 2.3/2.4. Ftape 4.0 is still elsewhere
This is wrong, since
Alexander Viro wrote:
>
> On Wed, 6 Sep 2000, Michael Elizabeth Chastain wrote:
>
> > We could use some more infrastructure here.
> >
> > (1) A 'make randomconfig' tool that generates a random configuration.
> >
> > (2) Make the architecture a configuration variable (!)
> >
> > (3) A collection
Alexander Viro wrote:
>
> On Wed, 6 Sep 2000, Martin Dalecki wrote:
>
> >
> > So may I just suggest to repleace the usage of cpp at all with something
> > more
> > suitable for the task at hand and with a much more regular/stringent
> > syntax
> >
David Howells wrote:
>
> I've done an implementation of some of the Win32 "system calls" in a kernel
> module in an attempt to speed up Wine.
Please by no way don't include this patch into the official tree.
It's insane due to the following:
1. Linux is UNIX not NT... (in terms of API)
2. WINE
Simon Richter wrote:
>
> On Thu, 7 Sep 2000, Martin Dalecki wrote:
>
> > > I've done an implementation of some of the Win32 "system calls" in a kernel
> > > module in an attempt to speed up Wine.
>
> > 1. Linux is UNIX not NT... (in terms of
Gary Lawrence Murphy wrote:
> The analogy to typing hex codes or toggling code at the console is
> also apt. Unix ascended over Multix in no small part because of C,
> which drew sneers from the trad programmer of the day. Personally, I
> tend to debug intuitively based on my knowledge of code,
Chris Evans wrote:
>
> On Tue, 12 Sep 2000, Hans Reiser wrote:
>
> > I really think Rik has it right here. In particular, an MP3 player
> > needs to be able to say, I have X milliseconds of buffer so make my
> > worst case latency X milliseconds. The number of requests is the
> > wrong metric,
Andrea Arcangeli wrote:
>
> On Tue, 12 Sep 2000, Martin Dalecki wrote:
>
> >First of all: In the case of the mp3 player and such there is already a
> >fine
> >proper way to give it better chances on getting it's job done smooth -
> >RT kernel sceduler pri
"Jeff V. Merkey" wrote:
> lessons learned in live customer accounts. In NetWare, requests are
> merged at A) the boundry between the File Cache and the I/O subsystem,
> and B) in the drivers themselves and NOT THE ELEVATOR.
Yes that's the proper place to do this. The generic elevator on a
*sin
Hans Reiser wrote:
>
> I really think Rik has it right here. In particular, an MP3 player needs to be able
>to say, I have
> X milliseconds of buffer so make my worst case latency X milliseconds. The number
>of requests is
> the wrong metric, because the time required per request depends on d
"Jeff V. Merkey" wrote:
>
> Martin,
>
> I'm glad you are not still mad at me. :-) I hope this info was
> helpful.
Yes it was in fact this one of the more interresting posts in this
thread. Thanks for the excellent reading. (However much of it
sounded very familiar... maybe they learned the sam
Andrea Arcangeli wrote:
>
> On Wed, 13 Sep 2000, Martin Dalecki wrote:
>
> >"Jeff V. Merkey" wrote:
> >
> >> lessons learned in live customer accounts. In NetWare, requests are
> >> merged at A) the boundry between the File Cache and the I/O sub
Andi Kleen wrote:
>
> On Wed, Sep 13, 2000 at 04:29:18PM +0200, Andrea Arcangeli wrote:
> > About B) I can' believe you seriously want to duplicate the merging code
> > in each lowlevel driver given most of them could share the same code (as
> > they're doing in linux).
>
> I guess it would just
"H. Peter Anvin" wrote:
>
> Followup to: <[EMAIL PROTECTED]>
> By author:John Byrne <[EMAIL PROTECTED]>
> In newsgroup: linux.dev.kernel
> >
> > Anyway, one of the things I was hoping to find out by going to
> > linux-kernel was if there was anything other than devfs in the offing:
> > such
Ricky Beam wrote:
>
> On Thu, 14 Sep 2000, Nick Pollitt wrote:
> ...
> >And second, why is the 4K limit there in the first place?
>
> Primarily because it was never designed for 90% of the crap that's in there
> now. I have long hated the BS required to get more than 4k worth of stuff
> out of
Andi Kleen wrote:
>
> On Tue, Sep 19, 2000 at 07:13:31PM -0400, Alexander Viro wrote:
> > Nice spotting, but bad fix, IMO. swab...() stuff is a perfect example of
> > the dangerous use of macros. BTW, 2.4 has the same problem.
>
> inlines usually generate worse code than macros (the gcc manual l
Hello!
Please have a look at the following patch and feel free to be scared
by the fact how UTTERLY BROKEN and ARBITRARY the current usage of the
read_ahead[] array and during the whole past decade was!
If you really care about clean internal interfaces this should be
one of those prio number ONE
Rik van Riel wrote:
>
> On Tue, 24 Oct 2000, Martin Dalecki wrote:
>
> > The most amanzing thing is that the whole test10-pre5 kernel
> > with this patch applied doesn't show any performance penalties
> > for me at all! And of corse it's about 10k smaller
Jeff Garzik wrote:
>
> > Please have a look at the following patch and feel free to be scared
> > by the fact how UTTERLY BROKEN and ARBITRARY the current usage of the
> > read_ahead[] array and during the whole past decade was!
> > If you really care about clean internal interfaces this should b
Peter Samuelson wrote:
>
> > So which is the recommended compiler for each kernel version 2.2.x,
> > 2.4.x(pre?) nowadays?
>
> * 2.91.66 aka egcs 1.1.2. It has been officially blessed for 2.4 and
> has been given an informal thumbs-up by Alan for 2.2. (It does NOT
> work for 2.0, if you st
Horst von Brand wrote:
>
> Red Hat 7.0, i686, gcc-20001027 (Yes, I know. Just to flush out bugs on
> both sides).
>
> abs() is used at least in:
>
> arch/i386/kernel/time.c
> drivers/md/raid1.c
> drivers/sound/sb_ess.c
>
> gcc warns about use of a non-declared function each time.
>
> No defin
Jakub Jelinek wrote:
>
> On Mon, Oct 30, 2000 at 03:01:16PM +0100, Martin Dalecki wrote:
> > Horst von Brand wrote:
> > >
> > > Red Hat 7.0, i686, gcc-20001027 (Yes, I know. Just to flush out bugs on
> > > both sides).
> > >
> > > abs()
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
> > close.
>
> I dunno. The main re
Horst von Brand wrote:
>
> Martin Dalecki <[EMAIL PROTECTED]> said:
> > Peter Samuelson wrote:
>
> [...]
>
> > > * Red Hat "2.96" or CVS 2.97 will probably break any known kernel.
>
> > Works fine for me and 2.4.0-test10-pre5... howe
Richard Henderson wrote:
>
> On Wed, Nov 01, 2000 at 09:46:19AM -0500, [EMAIL PROTECTED] wrote:
> > What versions of gcc produce the built-in functions?
>
> 2.95 and previous. In 2.96 somewhere we fixed a bug that
> automatically prototypes these builtin functions for you;
> ie with current cod
Mo McKinlay wrote:
>
> I recently obtained an HP Omnibook XE2 laptop. It's a reasonably
> nicely-specced machine, although (unsuprsingly) the hardware isn't too
> well supported with Linux.
>
> I've given up on the internal modem (I'm 90% sure it's some kind of
> software modem, and I have an ex
Tim Riker wrote:
>
> ok, a very valid point. The "C++ kernel code" reference is very telling.
> (ouch). ;-)
>
> Obviously the changes to support non-gcc compilers should have the goal
> of minimal impact on gcc users lives. I recognize that the mainstream
> will still use gcc.
>
> Q: Why should
David Woodhouse wrote:
>
> [EMAIL PROTECTED] said:
> > * Driver initializes mixer to 100% muted * Userspace app sets desired
> > values to /dev/mixer * Userspace app opens /dev/dsp to play sound
>
> > I don't see where any sound can "escape" in this scenario, and it
> > doesn't require any modu
Alan Cox wrote:
>
> > >Just load the driver at bootup and forget about it. Problem solved.
> >
> > I daily curse the name of whoever added autoload and autounload.
> > Autoload maybe useful, autounload is just asking for problems.
>
> Deal with it. Hardware is also now auto load and auto unload
Martin Mares wrote:
>
> Hi Alan!
>
> > If the sound card is only used some of the time or setup and then used
> > for TV its nice to get the 60K + 128K DMA buffer back when you dont need it
> > especially on a low end box
>
> So why don't we allocate / free the DMA buffer on device open / close
Alexander Viro wrote:
>
> 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 technical stuf
Dietmar Kling wrote:
>
> Ok guys i take your arguments...
> (i really loved to hear them)
>
> and i'd like to continue them in a
> private discussion( but i am
> tired now ... :) )
>
> but a last one i cannot resist...
>
>
> but why are your ideas not widespread and
> so successful like kde,g
"Justin T. Gibbs" wrote:
>
> >> BSD has curproc, but that is considerably less likely to be
> >> used in "inoccent code" than "current". I mean, "current what?".
> >> It could be anything, current privledges, current process, current
> >> thread, the current time...
> >
> >I see and I assume cal
"Justin T. Gibbs" wrote:
>
> >
> >What's wrong with current? It's perfectly fine, since it's the main data
> >context entity you are working with during it's usage... Just remember
> >it as
> >CURRENT MAIN PROBLEM the kernel is struggling with at time.
>
> What's wrong with the aic7xxx driver st
Dnia Wto 19. Grudzie? 2000 18:45, Andries Brouwer napisa?:
> On Tue, Dec 19, 2000 at 06:14:04AM -0500, Paul Gortmaker wrote:
> > I always disliked the unknown partition table messages you get when you
> > mke2fs a whole disk and don't bother with a table at all, so I fixed it.
> > Output before/af
Ragnar Hojland Espinosa wrote:
>
> On Thu, Sep 28, 2000 at 01:45:40AM +0200, Igmar Palsenberg wrote:
> > Some arguments why not to use it in the kernel :
> >
> > - C++ gives overhead. With something like a kernel that's unwanted.
>
> You pay for what you use, no less no more. C++ compilers don'
Marc Lehmann wrote:
>
> On Sat, Sep 30, 2000 at 03:07:49PM +0100, Alan Cox <[EMAIL PROTECTED]> wrote:
> > > If you don't like this, I suggest you send mail complaining to RedHat.
> > > Customer complaints are going to be the only way that RH is going to be
> > > influenced not to play games like
Alan Cox wrote:
>
> > > They released a supported ex-Cygnus people approved compiler.
> >
> > Which still makes it an broken, experimental, unreleased and unofficial
> > compiler, with all the consequences I said.
>
> And didnt you write something called pgcc once.
And then there isn't anything
Marc Lehmann wrote:
> If you disagree personally or technically with me you either say this
> in public or private or keep quiet. Attacking me over totally unrelated
> things is obviously some maneuver to distract people from the real,
> kernel-related question, and I have no idea why you are doin
Richard Henderson wrote:
> Frankly, I didn't even consider C++ ABI compatibility with other
> Linux vendors, since I think that's a losing proposition until
> everyone is using gcc3. We were _already_ incompatible, since
> there are a mix of egcs and gcc versions involved.
C++ ABI breaking: SuSE
Igmar Palsenberg wrote:
>
> > I wouldn't mind, either, if this didn't mean that programs compiled
> > on rehdat need redhat versions of the development toolchain / runtime
> > environment to use them :(
Ever tried to recompile SuSE apache from the src.rpm they provide?
I wish you good louck gett
Elmer Joandi wrote:
>
> > understanding the
> > > underlying principles and the code.
>
> Speaking about that, I have been long time dreaming
> about following strict standard template for linux kernel functions:
> (macroplay intended)
> --
> INLINE(context,level,for_speed,
Ingo Molnar wrote:
>
> On Tue, 5 Sep 2000, Andi Kleen wrote:
>
> > My point was basically that omitting useful debugging tools makes it
> > not any less likely that people use the (A) strategy (easy fix instead
> > of real understanding). For some people it is so painfull to work with
> > raw du
"Jeff V. Merkey" wrote:
>
> Ingo Molnar wrote:
> >
> > On Tue, 5 Sep 2000, Jeff V. Merkey wrote:
> >
> > > Your arguments are personal, not technical. [...]
> >
> > no, my arguments are technical, but are simply focused towards the
> > conceptual (horizontal) development of Linux, not the vertica
Andrea Arcangeli wrote:
>
> On Wed, Sep 20, 2000 at 01:22:50AM +0200, Andi Kleen wrote:
> > Better would be to use statement blocks like
> > #define bla(x) ({ __u32 tmp__ = (x); ; tmp__; })
>
> Agreed.
Not agreed. In this case older version of GCC will have
almost exactly the same provlems
"Albert D. Cahalan" wrote:
>
> Geert Uytterhoeven writes:
>
> > - The colors for the 16 color logo are wrong. We used a hack to
> > give the logo its own color palette, but this no longer works
> > as a side effect of a console color map bug being fixed a while
> > ago. The solutio
Alan Cox wrote:
>
> > My work will concern with the internationalization of Linux
> > So, could anybody tell me what kinds of features should be in the
> > consideration when linux be localized from english to Japanese or chinese,
> > say using 2 bytes character set.
>
> Most of the Linux usersp
Rik van Riel wrote:
>
> On Tue, 13 Mar 2001, Albert D. Cahalan wrote:
>
> > Bloat removal: being able to run without /proc mounted.
> >
> > We don't have "kernel speed". We have kernel-mode screwing around
> > with text formatting.
>
> Sounds like you might want to maintain an external patch
>
Jonathan Morton wrote:
>
> >> If crashes are routine on this machine, I'd recommend that you take
> >> a serious look at your ram. (or if you're overclocking, don't)
> >
> >Crashes were routine, and I was not overclocking, so I took Mike's
> >advice and bought a new 256MB DIMM. The computer hasn'
Rik van Riel wrote:
>
> On Sat, 23 Mar 2002, Martin Dalecki wrote:
>
> > Uptime of a process is a much better mesaure for a killing
> > candidate then it's size.
>
> You'll have fun with your root shell, then ;)
You mean the remote one?
> The current
Stephen Clouse wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Sat, Mar 23, 2002 at 01:33:50AM +0100, Martin Dalecki wrote:
> > AMEN! TO THIS!
> > Uptime of a process is a much better mesaure for a killing candidate
> > then it's size.
&
Rik van Riel wrote:
>
> On Sat, 23 Mar 2002, Martin Dalecki wrote:
>
> > This is due to the broken calculation formula in oom_kill().
>
> Feel free to write better-working code.
I don't get paid for it and I'm not idling through my days...
-
To unsubscrib
SodaPop wrote:
>
> Rik, is there any way we could get a /proc entry for this, so that one
> could do something like:
I will respond; NO there is no way for security reasons this is not a
good idea.
> cat /proc/oom-kill-scores | sort +3
-
To unsubscribe from this list: send the line "unsubscrib
I have a constructive proposal:
It would make much sense to make the oom killer
leave not just root processes alone but processes belonging to a UID
lower
then a certain value as well (500). This would be:
1. Easly managable by the admin. Just let oracle/www and analogous users
have a UID low
[EMAIL PROTECTED] wrote:
>
> Please point me to an Operating System that runs on any commonly available
> platform and fits your requirements.
> Nick
You don't beleve me if I tell you: DOS extender and JVM (Java Virtual
Machine)
-
To unsubscribe from this list: send the line "unsubscribe
SodaPop wrote:
>
> On Fri, 23 Mar 2001, Martin Dalecki wrote:
>
> > SodaPop wrote:
> > >
> > > Rik, is there any way we could get a /proc entry for this, so that one
> > > could do something like:
> >
> > I will respond; NO there is n
[EMAIL PROTECTED] wrote:
>
> [to various people]
>
> No, ulimit does not work. (But it helps a little.)
> No, /proc/sys/vm/overcommit_memory does not work.
>
> [to Alan]
>
> > Nobody feels its very important because nobody has implemented it.
>
> Yes, that is the right response.
> What can on
Martin Dalecki wrote:
>
> I have a constructive proposal:
>
> It would make much sense to make the oom killer
> leave not just root processes alone but processes belonging to a UID
> lower
> then a certain value as well (500). This would be:
>
> 1. Easly managable by
Doug Ledford wrote:
>
> Horst von Brand wrote:
> >
> > "Christian Bodmer" <[EMAIL PROTECTED]> said:
> >
> > > I can't say I understand the whole MM system, however the random killing
> > > of processes seems like a rather unfortunate solution to the problem. If
> > > someone has a spare minute, m
Mike Galbraith wrote:
>
> On Sat, 24 Mar 2001, Doug Ledford wrote:
>
> [snip list of naughty behavior]
>
> > What was that you were saying about "should *never* happen"? Oh, and let's
> Get off your lazy butts and do something about it. Don't work on the
> oom-killer though.. that's only a sy
Jeff Garzik wrote:
>
> Also for 2.5, kdev_t needs to go away, along with all those arrays based
> on major number, and be replaced with either "struct char_device" or
> "struct block_device" depending on the device.
>
> I actually went through the kernel in 2.4.0-test days and did this.
> Most k
Benoit Garnier wrote:
>
> Szabolcs Szakacsits wrote :
>
> > But if you start
> > to think you get the conclusion that process killing can't be avoided if
> > you want the system keep running.
>
> What's the point in keeping the OS running if the applications are silently
> killed?
>
> If your
Jonathan Morton wrote:
>
> >Right now my best approximation is to make the OOM test be as optimistic as
> >it is safe to be, and the vm_enough_memory() test as pessimistic as
> >sensible. Expect a test patch to appear on this list soon.
>
> ...and here it is!
>
> This fixes a number of small b
Stephen Satchell wrote:
>
> At 12:41 AM 3/25/01 +0100, you wrote:
> >If your box is running for example a mail server, and it appears that
> >another process is juste eating the free memory, do you really want to kill
> >the mail server, just because it's the main process and consuming more
> >me
Linus Torvalds wrote:
>
> On Sat, 24 Mar 2001 [EMAIL PROTECTED] wrote:
> >
> > We need a size, and I am strongly in favor of sizeof(dev_t) = 8;
> > this is already true in glibc.
>
> The fact that glibc is a quivering mass of bloat, and total and utter crap
> makes you suggest that the Linux ker
Rik van Riel wrote:
>
> On Sun, 25 Mar 2001, Martin Dalecki wrote:
>
> > Ah... and of course I think this patch can already go directly
> > into the official kernel. The quality of code should permit
> > it. I would esp. request Rik van Riel to have a closer l
Alan Cox wrote:
>
> > That depends what you mean by "must not". If it's your missile guidance
> > system, aircraft autopilot or life support system, the system must not run
> > out of memory in the first place. If the system breaks down badly, killing
> > init and thus panicking (hence rebooting,
Jonathan Morton wrote:
>
> >- the AGE_FACTOR calculation will overflow after the system has
> > an uptime of just _3_ days
>
> Tsk tsk tsk...
>
> >Now if you can make something which preserves the heuristics which
> >serve us so well on desktop boxes and add something that makes it
> >also wor
"Eric W. Biederman" wrote:
>
> Matthew Wilcox <[EMAIL PROTECTED]> writes:
>
> > On Mon, Mar 26, 2001 at 10:47:13AM -0700, Andreas Dilger wrote:
> > > What do you mean by problems 5 years down the road? The real issue is that
> > > this 32-bit block count limit affects composite devices like MD
Jonathan Morton wrote:
>
> >Out of Memory: Killed process 117 (sendmail).
> >
> >What we did to run it out of memory, I don't know. But I do know that
> >it shouldn't be killing one process more than once... (the process
> >should not exist after one try...)
>
> This is a known bug in the Out-of
Michel Wilson wrote:
>
> > relative ages. The major flaw in my code is that a sufficiently
> > long-lived
> > process becomes virtually immortal, even if it happens to spring a serious
> > leak after this time - the flaw in yours is that system processes
>
> I think this could easily be fixed i
Jonathan Morton wrote:
>
> Oh and BTW, I think Bit/sqr(seconds) is a perfectly acceptable unit for
> "badness". Think about it - it increases with pigginess and decreases with
> longevity. I really don't see a problem with it per se.
Right it's not a problem pre se, but as you already explain
Ingo Oeser wrote:
>
> On Tue, Mar 27, 2001 at 03:24:16PM +0200, Martin Dalecki wrote:
> > > @@ -93,6 +95,10 @@
> > > p->uid == 0 || p->euid == 0)
> > > points /= 4;
> > >
> > >
"H. Peter Anvin" wrote:
>
> This is my opinion on the issue. Short summary: "I'm sick of the
> administrative burden associated with keeping dev_t dense."
>
> Linus Torvalds wrote:
> >
> > And let's take a look at /dev. Do a "ls -l /dev" and think about it. Every
> > device needs a unique numbe
"H. Peter Anvin" wrote:
>
> Alan Cox wrote:
> >
> > > Another example: all the stupid pseudo-SCSI drivers that got their own
> > > major numbers, and wanted their very own names in /dev. They are BAD for
> > > the user. Install-scripts etc used to be able to just test /dev/hd[a-d]
> > > and /dev/
Alan Cox wrote:
>
> > high-end-disks. Rather the reverse. I'm advocating the SCSI layer not
> > hogging a major number, but letting low-level drivers get at _their_
> > requests directly.
>
> A major for 'disk' generically makes total sense. Classing raid controllers
> as 'scsi' isnt neccessaril
Linus Torvalds wrote:
>
> On Tue, 27 Mar 2001, Andre Hedrick wrote:
> >
> > Am I hearing you state you want dynamic device points and dynamic majors?
>
> Yes and no.
>
> We need static structures for user space - from a user perspective it
> makes a ton more sense to say "I want to see all disk
> what do other vaguely unix-like systems do? does, say, plan9 have a
> better way of dealing with all this?
Yes.
Normal UNIX has as well. For reffernece see: block ver raw
devices on docs.sun.com :-).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a m
Alan Cox wrote:
>
> > Exactly. It's just that for historical reasons, I think the major for
> > "disk" should be either the old IDE or SCSI one, which just can show more
> > devices. That way old installers etc work without having to suddenly start
> > knowing about /dev/disk0.
>
> They will mos
Alan Cox wrote:
>
> > Why do you worry about installers? New distro - new kernel - new
> > installer
>
> Because the same code tends to be shared with post install configuration
> tools too.
So change them as well for a new distribution. What's there problem.
There isn't anything out there you
Linus Torvalds wrote:
>
> On Tue, 6 Feb 2001, Ben LaHaise wrote:
> >
> > On Tue, 6 Feb 2001, Stephen C. Tweedie wrote:
> >
> > > The whole point of the post was that it is merging, not splitting,
> > > which is troublesome. How are you going to merge requests without
> > > having chains of scatt
Linus Torvalds wrote:
>
> On Thu, 8 Feb 2001, Rik van Riel wrote:
>
> > On Thu, 8 Feb 2001, Mikulas Patocka wrote:
> >
> > > > > You need aio_open.
> > > > Could you explain this?
> > >
> > > If the server is sending many small files, disk spends huge
> > > amount time walking directory tree and
[EMAIL PROTECTED] wrote:
>
> > They are entirely different. Too different sets of operations.
>
> Maybe you didnt understand what I meant.
> both bdev and cdev take care of the correspondence
> device number <---> struct with operations.
>
> The operations are different, but all bdev/cdev code
[EMAIL PROTECTED] wrote:
>
> Martin Dalecki writes:
>
> > I fully agree with you.
>
> Good.
>
> Unfortunately I do not fully agree with you.
>
> > Most of the places where there kernel is passing kdev_t
> > would be entierly satisfied with only the k
1 - 100 of 127 matches
Mail list logo
