Derek Vadala writes:
> It's clear that under 2.4, the kernel imposes a limit of 2TB as the
> maximum file size and that some portion of the kernels before 2.4 had a
> limit of 2GB.
>
> However, it's not clear to me when the file size limit was increased, or
> what the maximum file system sizes un
Rob Landley writes:
> Off the top of my head, fun things you can't do suid root:
...
> ps (What the...? Worked in Red Hat 7, but not in suse 7.1.
> Huh? "suid-to apache ps ax" works fine, though...)
The ps command used to require setuid root. People would set the
bit by habit.
> I keep bump
Wakko Warner writes:
> I believe there is. It wants to find what drive is bios drive 80h. Really
> annoying since there's no way (correct me if I'm wrong) to read bios from
> linux. If there is, lilo should do that. But since it's an old copy, this
> probably was fixed.
>
> I had a machine at
> Almost always ?
> It seems like gcc is THE ONLY program which gets
> signal 11
> Why the X server doesn't get signal 11 ?
> Why others programs don't get signal 11 ?
...
> Some time ago I installed Linux (Redhat 6.0) on my
> pc (Cx486 8M RAM) and gcc had a lot of signal 11 (a
> couple every hou
Sean Hunter writes:
> On Wed, Jun 27, 2001 at 04:55:56PM -0400, Albert D. Cahalan wrote:
>> ln /dev/zero /tmp/zero
>> ln /dev/hda ~/hda
>> ln /dev/mem /var/tmp/README
>
> None of these (of course) work if you use mount options to
> restrict device nodes on those fi
H. Peter Anvin writes:
> "Albert D. Cahalan" wrote:
>> BTW, it is way wrong that /dev/zero should be needed at all.
>> Such use is undocumented ("man zero", "man mmap") anyway, and
>> AFAIK one should use mmap() with MAP_ANON instead. Not that
H. Peter Anvin writes:
> Albert D. Cahalan wrote:
>> Normal users can use an environment provided for them.
>>
>> While trying to figure out why the "heyu" program would not
>> work on a Red Hat box, I did just this. As root I set up all
>> the device f
H. Peter Anvin writes:
> [somebody]
>> Have you ever wondered why normal users are not allowed to chroot?
>>
>> I have. The reasons I can figure out are:
>>
>> * Changing root makes it trivial to trick suid/sgid binaries to do
>> nasty things.
>>
>> * If root calls chroot and changes uid, he ex
Kenneth Johansson writes:
> Do linux even support the sticky bit (t) I can't see a reason
> to use it, why would I want the file to be stored in the swap ??
It is not currently supported. Swapping out executables would
be very nice when using an NFS or CD-ROM filesystem, because
swap space is m
Daniel Phillips writes:
> On Monday 25 June 2001 00:54, Albert D. Cahalan wrote:
>> By dumb luck (?), FAT32 is compatible with the phase-tree algorithm
>> as seen in Tux2. This means it offers full data integrity.
>> Yep, it whips your typical journalling filesystem. Look
By dumb luck (?), FAT32 is compatible with the phase-tree algorithm
as seen in Tux2. This means it offers full data integrity.
Yep, it whips your typical journalling filesystem. Look at what
we have in the superblock (boot sector):
__u32 fat32_length; /* sectors/FAT */
__u16 flags;
Allan Duncan writes:
> Since the 2.4.x advent of shm as tmpfs or thereabouts,
> /proc/meminfo shows shared memory as 0. It is in
> reality not zero, and is being allocated, and shows
> up in /proc/sysvipc/shm and /proc/sys/kernel/shmall
> etc..
> Neither 2.4.6-pre5 nor 2.4.5-ac17 have the correc
Alan Cox writes:
> [somebody]
>> I could not find any reference to BIOS int 0x15, function 0x87,
>> block-move, used to copy the kernel to above the 1 megabyte
>> real-mode boundary. I think this is still used.
>
> I dont think the kernel has ever used it. The path has always been to
> enter 32bi
Zach Brown writes:
> The attached patch-in-progress removes the per-cpu statistics from
> struct kernel_stat and puts them in a cpu_stat structure, one per cpu,
> cacheline padded. The data is still coolated and presented through
> /proc/stat, but another file /proc/cpustat is also added. The l
Rob Landley writes:
> On Wednesday 20 June 2001 15:53, Martin Dalecki wrote:
>> Mike Harrold wrote:
>> super computing, hmm what about some PowerPC CPU variant - they very
>> compettetiv in terms of cost and FPU performance! Transmeta isn't the
>> adequate choice here.
>
> You honestly think you
Rob Landley writes:
> My only real gripe with Linux's threads right now [...] is
> that ps and top and such aren't thread aware and don't group them
> right.
>
> I'm told they added some kind of "threadgroup" field to processes
> that allows top and ps and such to get the display right. I haven'
Pozsar Balazs writes:
> I'm having ~2 lockups a day. The following happens:
> If I was under X, i only can use the magic-key, but no other keyboard (eg
> numlock) or mouse response, the screen freezes, processes stop.
> If i was using textmode:
> numlock still works
> cursor blinks
> proc
Daniel Phillips writes:
> On Friday 15 June 2001 21:21, Albert D. Cahalan wrote:
>> Non-blinking cursors are just wrong. You need to patch your brain.
>> You really fucked up, because now apps can't restore your cursor
>> to proper behavior as defined by IBM.
>
&g
Leon Breedt writes:
> Attached is a patch to enforce a non-blinking, FreeBSD-syscons like
> block cursor in console mode.
>
> This is useful for laptop types, or people like me who really really
> detest a blinking cursor.
>
> NOTE: It disables the softcursor escape codes
> (/usr/src/lin
Mike Black writes:
> I'm concerned that you're probably just overruning your IP stack:
...
> TCP is NOT a guaranteed protocol -- you can't just blast data from one port
> to another and expect it to work.
Yes you can. This is why we have TCP in fact.
> a tcp-write is NOT guaranteed -- and as yo
David S. Miller writes:
> Jeff Garzik writes:
>> According to the PCI spec it is -impossible- to have more than 256
>> buses on a single "hose", so you simply have to implement multiple
>> hoses, just like Alpha (and Sparc64?) already do. That's how the
>> hardware is forced to implement it...
>
Tom Gall writes:
> I was wondering if there are any other folks out there like me who
> have the 256 PCI bus limit looking at them straight in the face?
I might. The need to reserve bus numbers for hot-plug looks like
a quick way to waste all 256 bus numbers.
> each PHB has an
> additional id
Zehetbauer Thomas writes:
> Has someone experimented with running linux in little-endian mode on IBM
> PowerPC 405 (Walnut) yet?
I doubt it. You are at least the 3rd person to want little-endian.
Somebody at Matrox posted a patch for little-endian on the 74xx.
You need a bit more than that thoug
Michael H. Warfiel writes:
> On Fri, Jun 08, 2001 at 05:16:39PM -0400, Albert D. Cahalan wrote:
>> The bits are free; the API is hard to change.
>> Sensors might get better, at least on high-end systems.
>> Rounding gives a constant 0.15 degree error.
>> Only th
Struct padding is a problem. Really, there shouldn't be any
implicit padding. This causes:
1. security leaks when such structs are copied to userspace
(the implicit padding is uninitialized, and so may contain
a chunk of somebody's private key or password)
2. bloat, when struct members cou
Michael H. Warfiel writes:
> On Fri, Jun 08, 2001 at 05:16:39PM -0400, Albert D. Cahalan wrote:
>> The bits are free; the API is hard to change.
>> Sensors might get better, at least on high-end systems.
>> Rounding gives a constant 0.15 degree error.
>> Only th
John Chris Wren writes:
> coupling to the CPU that is about as bad as it can get. You've got an epoxy
> housing of an inconsistent shape in contact with ceramic. The actual
> contact point is miniscule. There's no thermal paste, and often, I've seen
> the sensors not quite raised high enough t
Henning P. Schmied writes:
> Alan Cox <[EMAIL PROTECTED]> writes:
>> So it comes down to the question of whether the module is linking
>> (which is about dependancies and requirements) and what the legal
>> scope is. Which is a matter for lawyers.
>
> And this would void DaveMs' argument, that on
L. K. writes:
> On Fri, 8 Jun 2001, Albert D. Cahalan wrote:
>> The bits are free; the API is hard to change.
>> Sensors might get better, at least on high-end systems.
>> Rounding gives a constant 0.15 degree error.
>> Only the truly stupid would assume accuracy fr
Michael H. Warfiel writes:
> We don't have sensors that are accurate to 1/10 of a K and certainly not
> to 1/100 of a K. Knowing the CPU temperature "precise" to .01 K when
> the accuracy of the best sensor we are likely to see is no better than
> +- 1 K is just about as relevant as negative abs
Chris Boot writes:
Kelvins good idea in general - it is always positive ;-)
0.01*K fits in 16 bits and gives reasonable range.
...
> OK, I think by now we've all agreed the following:
> - The issue is NOT displaying temperatures to the user, but a userspace
>program reading th
Jan Kasprzak writes:
> Another goal is to use the Linux filesystem
> as a backing store (as opposed to the block device or single large file
> used by CODA).
...
> - kernel module, implementing the filesystem of the type "cachefs"
> and a character device /dev/ca
L. K. writes:
> Why not make it in Celsius ? Is more easy to read it this way.
No, because then the software must handle negative numbers for
cooled computers. CentiKelvin is fine. Do C=cK/100-273.15 if you
really must... but you still have a number that is useless to
a human. Humans need a seco
David S. Miller writes:
> David Woodhouse writes:
>>> Call it flush_ecache_full() or something.
>>
>> Strange name. Why? How about __flush_cache_range()?
>
> How about flush_cache_range_force() instead?
>
> I want something in the name that tells the reader "this flushes
> the caches, even though
Paul Mackerras writes:
> The only valid reason for userspace programs to be including kernel
> headers is to get definitions that are part of the kernel API. (And
> in fact others here will go further and assert that there are *no*
> valid reasons for userspace programs to include kernel headers
Alexander Viro writes:
> leaves ncp with its ioctls ugliness.
Authentication will be ugly. Joe mounts a filesystem, and does
not bother to authenticate. He gets world-accessible files.
Then Kevin authenticates as himself, and later as db_adm too.
Along comes Sue, who can authenticate the whole b
[EMAIL PROTECTED] writes:
> This is probably an FAQ, but I read the FAQ and its not in there.
Odd.
> I have a machine with 2G of memory. I compiled the kernel with the
> 4G memory option. How much address space should each process be
> able to address?
3 GB for user stuff, or 3.5 GB with a p
Harald Welte writes:
> Is there any way to read out the compile-time HZ value of the kernel?
>
> I had a brief look at /proc/* and didn't find anything.
Look again, this time with a sick mind. Got your barf bag?
Kubys made me do it.
/
Jonathan Lundell writes:
> At 5:07 PM -0700 2001-05-30, H. Peter Anvin wrote:
>>> If you now want to set those values from a userspace program / script in
>>> a portable manner, you need to be able to find out of HZ of the currently
>>> running kernel.
>>
>> Yes, but that's because the interfac
David S. Miller
> Ingo Molnar writes:
>> (unlike bottom halves, soft-IRQs do not preempt kernel code.)
> ...
>
> Since when do we have this rule? :-)
...
> You should check Softirqs on return from every single IRQ.
> In do_softirq() it will make sure that we won't run softirqs
> while already doi
Mark Hahn writes:
> contrary to the implication here, I don't believe there is any *general*
> problem with Linux/VIA/AMD stability. there are well-known issues
> with specific items (VIA 686b, for instance), but VIA/AMD hardware
> is quite suitable for servers.
VIA hardware is not suitable for
Oliver Xymoron writes:
> The /dev dir should not be special. At least not to the kernel. I have
> device files in places other than /dev, and you probably do too (hint:
> anonymous FTP).
This is a horribly broken FTP server.
-
To unsubscribe from this list: send the line "unsubscribe linux-kerne
David S. Miller writes:
> What are these "devices", and what drivers "just program the cards to
> start the dma on those hundred mbyte of ram"?
Hmmm, I have a few cards that are used that way. They are used
for communication between nodes of a cluster.
One might put 16 cards in a system. The ca
Guest section DW writes:
> On Thu, May 17, 2001 at 02:35:55AM -0400, Albert D. Cahalan wrote:
>> The PC partition table has such an ID. The LILO change log
>> mentions it. I think it's 6 random bytes, with some restriction
>> about being non-zero.
>
> You a
Bingner Sam J. Con writes:
> Looks to me like it's adding { and } on each side of the
> "c->devices->prev=d;" statement... so changing from:
>
> if (c->devices != NULL)
> c->devices->prev=d;
>
> to
>
> if (c->devices != NULL){
> c->devices->prev=d;
> }
>
> I assume the new compil
Heinz J. Mauelshag writes:
> LVM does a similar thing storing UUIDs in its private metadata
> area on every device used by it.
>
> Problem is: neither MD nor LVM define a standard in Linux
> which *needs* to be used on every device!
>
> It is just up to the user to configure devices with them or
Jeff Garzik writes:
> "Khachaturov, Vassilii" wrote:
>> Can someone please confirm if my assumptions below are correct:
>> 1) Unless someone specifically tampered with my driver's device
>> since the OS bootup, the mapping of the PCI base address registers
>> to virtual memory will remain the sam
H. Peter Anvin writes:
> This would leave no way (without introducing new interfaces) to write,
> for example, the boot block on an ext2 filesystem. Note that the
> bootblock (defined as the first 1024 bytes) is not actually used by
> the filesystem, although depending on the block size it may s
Daniel Phillips writes:
> On Monday 14 May 2001 07:29, Blesson Paul wrote:
>>I am trying to implement a distributed file system.
Me too! :-)
>> For that I write a file driver. I want to know the following things
>>
>> 1 . If I am writing a new file system, is it necessary to mo
Blesson Paul writes:
> This is an another doubt related to VFS. I want to know
> wheather all files are assigned their inode number at the
> mounting time itself or inodes are assigned to files upon
> accessing only
That would depend on what type of filesystem you use.
For ext2, inode numbers ar
Hans Reiser writes:
> Tell us what to code for, and so long as it doesn't involve looking
> up files by their 32 bit inode numbers we'll probably be happy to
> code to it. The Neil Brown stuff is already coded for though.
Next time around, when you update the on-disk format, how about
allowing
Jeff Garzik writes:
> Pavel Roskin wrote:
>> You may need to save some data in memory when the system goes
>> to suspend and restore them afterwards. I believe that the PCI
>> config space should be saved by BIOS. Everything else is the
>> responsibility of the driver.
>
> In ACPI land the kernel
Pete Zaitcev writes:
> Russel King complained that you might be calling pci_consistent_free
> from an interrupt, which is unsafe on ARM.
This sure makes life difficult. Device removal events can be called
from interrupt context according to Documentation/pci.txt. This is
certainly a place where
Pierre Rousselet writes:
> James Bourne wrote:
>> From the procps man page:
>>Albert Cahalan <[EMAIL PROTECTED]> rewrote ps for full
>>Unix98 and BSD support, along with some ugly hacks for
>>obsolete and foreign syntax.
>>
>>Michael K. Johnson <[EMAIL PROTE
=?iso-8859-1?Q?Jak writes:
> Hi, just wanted to recommend that this goes in, in one form or
> another - it would help a lot around here.
Yes, it looks very nice. The codes match those used by ps even.
> Today we have to manually "fix" the kernel
> source to get proper core.[executable] naming
Alexander Viro writes:
>> On Fri, 4 May 2001, Alexander Viro wrote:
>>> Ehh... There _is_ a way to deal with that, but it's deeply Albertesque:
> ^^^
Ah, you learn from the master.
> ObProcfs: I don't think that walking the pa
Duncan Gauld writes:
> Information in the README file says that when patching, the -p0 option is
> used with patch (eg tar xvzf .tar.gz | patch -p0). However I have
> never got this to work as I always get something like "can't find file to
> patch at line 5". However, replacing -p0 with -p1 s
Pavel Machek writes:
> It should ot break anything. gcc decides its bad to inline it, so it
> does not inline it. Small code growth at worst. Compiler has right to
> make your code bigger or slower, if it decides to do so.
Oh come on. The logical way:
inline Compiler must inline (only
Tom Holroyd writes:
> On Wed, 2 May 2001, Albert D. Cahalan wrote:
>> For 32-bit systems, we use 32-bit values to reduce overhead.
>> This causes problems at 495/smp_num_cpus days of uptime.
>
> You mean for HZ == 100.
Well, OK. No unmodified 32-bit system runs HZ == 102
> /proc/uptime:
> 4400586.27 150439.36
>
> /proc/stat:
> cpu 371049158 3972370867 8752820 4448994822
> (user,nice, system, idle)
>
> In .../fs/proc/proc_misc.c:kstat_read_proc(), the cpu line is being
> computed by:
>
> len = sprintf(page, "cpu %u %u %u %lu\n", user, nic
Linus Torvalds writes:
> Btw, please use "static inline" instead of "extern inline", as gcc may
> decide not to inline the latter at all, leading to confusing link-time
> errors. (Gcc may also decide not to inline "static inline", but then gcc
> will output the actual body of the function out-of-
What would be the cleanest driver that does everything right?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Rogier Wolff writes:
> Wakko Warner wrote:
>>> So you've spent almost $200 for RAM, and refuse to spend
>>> $4 for 1Gb of swap space. Fine with me.
So that is a factor of 50 in price. It's what, a factor of 100
in access time?
> That disk space is just sitting there. Never to be used. I sp
Linus Torvalds writes:
> The buffer cache is "virtual" in the sense that /dev/hda is a
> completely separate name-space from /dev/hda1, even if there
> is some physical overlap.
So the aliasing problems and elevator algorithm confusion remain?
Is this ever likely to change, and what is with the
[EMAIL PROTECTED] writes:
> i wrote somewhere that it was my mistake to call it single-user when i
> mean all user has the same root cap, and reduce "user" (account) to
> "profile".
Seen this way it makes a tad more sense:
1. you and your spouse share the computer
2. you have different shells,
[EMAIL PROTECTED] writes:
> i didn't change all uid/gid to 0!
>
> why? so with that radical patch, users will still have
> uid/gid so programs know the user's profile.
So you:
1. broke security (OK, fine...)
2. didn't remove all the support for security
It would be far more interesting to rip
Richard Gooch writes:
> We want to take out that union because it sucks for virtual
> filesystems. Besides, it's ugly.
I hope you won't mind if people trash this with benchmarks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECT
Wayne writes:
> In mailing-lists.linux-kernel, Manuel A. McLure wrote:
>> Did you try nesting more than one "su -"? The first one after a boot
>> works for me - every other one fails.
>
> Same here: the first "su -" works OK, but a second nested one hangs:
>
> 8825 pts/2S 0:00 /bin/su -
Eric S. Raymond writes:
> This is a proposal for an attribution metadata system in the Linux
> kernel sources. The goal of the system is to make it easy for
> people reading any given piece of code to identify the responsible
> maintainer. The motivation for this proposal is that the present
>
Matthew Wilcox writes:
> On Thu, Apr 19, 2001 at 10:07:22PM -0600, james rich wrote:
>> Doesn't this seem a little like the problems occurring with lvm right now?
>> A separate tree maintained with the maintainers not wanting others
>> submitting patches that conflict with their particular tree?
Theodore Tso writes:
> On Mon, Apr 16, 2001 at 05:53:19PM -0700, David S. Miller wrote:
>> It does not work in a relaxed "people sit at tables and comment
>> at arbitrary points in time during a talk" setting such as the
>> kernel summit. Besides putting a microphone at every table (which
>> isn
Nick Pollitt writes:
> Changes to array.c expose cpus_allowed in proc/pid/stat.
...
> -%lu %lu %lu %lu %lu %lu %lu %lu %d %d\n",
> +%lu %lu %lu %lu %lu %lu %lu %lu %d %d %lu\n",
...
> - task->processor);
> + task->processor,
> + task->cpus_allowed);
This isn
H. Peter Anvin writes:
> By author:"Heusden, Folkert van" <[EMAIL PROTECTED]>
>> Would anyone be intrested (besides me) in a kernel which can page
...
>> Certain parts of drivers could get the __pageable prefix or so
> VMS does this. It at least used to have a great tendency to crash
> itse
Miles Lane writes:
>> Randolph Bentson wrote:
>>> I've heard of conferences where a wireless audience
>>> microphone was put inside a Nerf ball. It could
>>> then be tossed to the audience member who wished
>>> to speak.
>
> Seriously though, this would probably still be an
> impediment to the s
> CLOCK_10MS a wall clock supporting timers with 10 ms resolution (same as
> linux today).
Except on the Alpha, and on some ARM systems, etc.
The HZ constant varies from 10 to 1200.
> At the same time we will NOT support the following clocks:
>
> CLOCK_VIRTUAL a clock measuring the elapsed exe
Guest section DW writes:
> On Mon, Apr 16, 2001 at 12:29:11AM -0600, Eric W. Biederman wrote:
>> If we can try to keycodes in 8-bits it would be nice. The difficulty
>> is that X cannot handle more than 8-bits without telling it you have
>> multiple keyboards. The keycode (at least in X) is exp
Andries.Brouwer writes:
>From [EMAIL PROTECTED] Mon Apr 16 08:35:09 2001
>>Andries.Brouwer writes:
>>> What one wants is to remap access to sector 0 to sector 1,
>>> and leave all other sectors alone. Thus, if someone asks
>>> for sectors 0 1 2 3 4, she should get sectors 1 1 2 3 4.
>>
>> No, bec
H. Peter Anvin writes:
> This means you don't have to configure two levels (scancodes ->
> keycodes and keycodes -> keymap); since currently the keycodes are
> keyboard-specific anyway there is no benefit to the two levels.
The medium-raw level ought to be what the X11R6 protocol uses.
Then the
Andries.Brouwer writes:
> What one wants is to remap access to sector 0 to sector 1,
> and leave all other sectors alone. Thus, if someone asks
> for sectors 0 1 2 3 4, she should get sectors 1 1 2 3 4.
No, because then you can't write to the real first sector.
Assuming translation is good, 1 0
> * Added fast-mode command to suppress side-effect computation
> on slow machines.
You could put the computation in a low-priority thread, so that it
still gets done but doesn't mess up responsiveness.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
th
> * All three interfaces do progressive disclosure -- the user only sees
> questions he/she needs to answer (no more hundreds of greyed-out menu
> entries for irrelevant drivers!).
Well, that sucks. The greyed-out menu entries were the only good
thing about xconfig. Such entries provide a clu
Martin Mares writes:
> [lost]
>> Just how would you do kernel/user CPU time accounting then ?
>> It's currently done on every timer tick, and doing it less
>> often would make it useless.
>
> Except for machines with very slow timers we really should account time
> to processes during context swi
Daniel Phillips writes:
> The zeroth block of an indexed directory is the index root. Initially
> the index has only one block. The following blocks are normal ext2
> directory entry blocks. When the directory grows large enough to fill
> all the available entries in the root index block (arou
> I'd prefer to inline cpu_is_idle(), but optimizing the idle
> code path is probably not that important ;-)
Sure it is, in one way: how fast can you get back to work?
(not OK to take a millisecond getting out of the idle loop)
-
To unsubscribe from this list: send the line "unsubscribe linux-ker
Gregory Maxwell writes:
> On Sun, Apr 01, 2001 at 03:43:52PM -0400, Albert D. Cahalan wrote:
>> I'm really sick of being buried in useless information. The signal
>> gets lost in the noise. It is easy to discard automatically generated
>> bug reports, and way too an
Manfred Spraul writes:
> [Larry McVoy]
>> There was a lot of discussion about possible tools
>> that would dig out the /proc/pci info
>
> I think the tools should not dig too much information out of the system.
> I remember some Microsoft (win98 beta?) bugtracking software that
> insisted on send
> Problem details
> Bug report quality
> There was lots of discussion on this. The main agreement was that we
> wanted the bug reporting system to dig out as much info as possible
> and prefill that. There was a lot of discussion about possible tools
> that would dig
Ingo Molnar writes:
> the attached pae-2.4.3-C3 patch fixes the PAE code to work with SLAB
> FORCED_DEBUG (which enables redzoning) too.
>
> the problem is that redzoning is enabled unconditionally, and SLAB has no
> information about how crutial alignment is in the case of any particular
> SLAB
Andrew Pimlott writes:
> On Tue, Mar 27, 2001 at 02:13:47PM -0800, H. Peter Anvin wrote:
>> The problems with devfs (other than kernel memory bloat, which is pretty
>> much guaranteed to be much worse than the bloat a larger dev_t would
>> entail) is that it needs complex auxilliary mechanisms to
[EMAIL PROTECTED] writes:
> [Linus Torvalds]
>> You'e now forced every piece of code that needs a dev_t
>> to carry along the overhead of having a 64-bit field
>
> Let me repeat: there is no such code. In user space dev_t already is
> 64 bits, whether you like it or not. We cannot go back to libc
Riley Williams writes:
> Hi Albert.
The rule should be like this:
List the lowest version number required to get
2.2.xx-level features while running a 2.4.xx kernel.
>>> Replace that "a 2.2.xx" with "my current" and remove all
>>> restrictions on what the current kernel
Riley Williams writes:
>> The rule should be like this:
>>
>> List the lowest version number required to get
>> 2.2.xx-level features while running a 2.4.xx kernel.
>
> That's a meaningless definition, and can only be taken as such. What
> use would such a list be to somebody wishing (l
Andries.Brouwer writes:
>> From: "Albert D. Cahalan" <[EMAIL PROTECTED]>
>>> On Wed, 14 Mar 2001 [EMAIL PROTECTED] wrote:
>>>>> +o Console Tools # 0.3.3# loadkeys -V
>>>>> +o Mount # 2.10e
Alexander Viro writes:
> On Wed, 14 Mar 2001 [EMAIL PROTECTED] wrote:
>>> +o Console Tools # 0.3.3# loadkeys -V
>>> +o Mount # 2.10e# mount --version
>>
>> Concerning mount: (i) the version mentioned is too old,
Exactly why? Mere missing features don't mak
Nathan Paul Simons writes:
> On Tue, Mar 13, 2001 at 04:05:13PM -0500, 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.
&
Nathan Paul Simons writes:
> On Mon, Mar 12, 2001 at 09:21:37PM +, Guennadi Liakhovetski wrote:
>> CPU utilisation. Each new application has to calculate it (ps, top, qps,
>> kps, various sysmons, procmons, etc.). Wouldn't it be worth it having a
>> syscall for that? Wouldn't it be more optim
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 solution is to replace the logo with a new one th
Jochen Dolze writes:
> i found at http://acl.bestbits.at the ACL-linux-project. Now i want to know,
> if there is a plan to integrate posix-ACLs into the fs-part of the kernel,
> e.g. into the VFS-Layer? Is there a general discussion about this anywhere?
> What are the biggest problems? (i know t
Hank Leininger writes:
> On 2001-03-07, "Albert D. Cahalan" <[EMAIL PROTECTED]> wrote:
>> Then for proper ps and top output, you need a reasonably efficient
>> way to grab all threads as a group. This could be as simple as
>> ensuring that /proc director
Helge Hafting writes:
> Gregory Maxwell wrote:
>> There are no threads in Linux.
>> All tasks are processes.
>> Processes can share any or none of a vast set of resources.
>
> Is there a way a user program can find out what resources
> are shared among which processes?
>
> That would allow enha
1 - 100 of 231 matches
Mail list logo
