On Mon, May 14, 2001 at 11:49:16PM -0400, God wrote:
> > Packets are dropped when a device queue
> > fills, and when one sender is much faster than the other the faster sender
> > often wins the race, while the packets of the slower one get dropped.
>
> [.]
>
> Speaking of queues on
Linus Torvalds writes:
>
> On Mon, 14 May 2001, Richard Gooch wrote:
> >
> > Is there some fundamental reason why a buffer cache can't ever be
> > fast?
>
> Yes.
>
> Or rather, there is a fundamental reason why we must NEVER EVER look at
> the buffer cache: it is not coherent with the page
Hi folks. I've never posted a kernel patch before, so I don't know if I
got it right. I followed the instructions in the FAQ... I'm not
subscribed, so if you could follow up to [EMAIL PROTECTED], I would
appreciate it.
This patch adds support for my sound card, which was an OEM version of
Oliver Neukum wrote:
> >
> > That's not the issue. LILO takes whatever you pass to root= and converts
> > it to a device number at /sbin/lilo time. An idiotic practice on the
> > part of LILO, in my opinion, that ought to have been fixed a long time
> > ago.
>
> And happily passes a "root="
On Tuesday, 15. May 2001 00:54, H. Peter Anvin wrote:
> Alexander Viro wrote:
> > On Mon, 14 May 2001, Alan Cox wrote:
> > > > > Except that Linus wont hand out major numbers, which means I can't
> > > > > even boot simply off such a device. I bet the vendors in question
> > > > > dont think the
Hi all
Thanks for the replies regarding inodes. From the replies I
understood that inode numbers are assigned at the time of accessing in the
case of msdos and nfs files. And it may change during running if it is not
being accessed.
Now the question is who is
On Mon, 14 May 2001, Linus Torvalds wrote:
>
> How hard is it to generate a new "disk driver framework", and let people
> register themselves, kind of like the "misc" drivers do. Except we'd only
> allow DISKS. You could add something like
>
> register_disk_driver("compaq-ciss",
On Mon, 14 May 2001, David S. Miller wrote:
>
> Larry McVoy writes:
> > Hell, that's the OS that gave us mmap, remember that?
>
> Larry, go read up on TOPS-20. :-) SunOS did give unix mmap(), but it
> did not come up the idea.
s/TOPS-20/Multics/
-
To unsubscribe from this list: send the
On Mon, 14 May 2001, Linus Torvalds wrote:
> The current page cache is completely non-coherent (with _anything_: it's
> not coherent with other files using a page cache because they have a
> different index, and it's not coherent with the buffer cache because that
> one isn't even in the same
Larry McVoy writes:
> Hell, that's the OS that gave us mmap, remember that?
Larry, go read up on TOPS-20. :-) SunOS did give unix mmap(), but it
did not come up the idea.
Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Mon, 14 May 2001, Larry McVoy wrote:
> Hell, that's the OS that gave us mmap, remember that?
"I got it from Agnes..."
Don't get me wrong, SunOS 4 was probably the nicest thing Sun had ever
released and I love it, but mmap(2) was _not_ the best of ideas. Files
as streams of bytes and
hello all:
--
Best Regard!
Àñ£¡
--
mail from: hugang [ºú¸Õ]
mail : [EMAIL PROTECTED] [EMAIL PROTECTED]
company : [EMAIL PROTECTED]
China Beijing Soul [±±¾©ÖÚÖ¾ºÏ´ï]
--
On Mon, 14 May 2001, Linus Torvalds wrote:
>
> Or rather, there is a fundamental reason why we must NEVER EVER look at
> the buffer cache: it is not coherent with the page cache.
>
> And keeping it coherent would be _extremely_ expensive. How do we
> know? Because we used to do that. Remember
On Mon, May 14, 2001 at 09:00:44PM -0700, Linus Torvalds wrote:
> Or rather, there is a fundamental reason why we must NEVER EVER look at
> the buffer cache: it is not coherent with the page cache.
Not that Linus needs any backing up but Sun got rid of the buffer cache
and just had a page cache
On Mon, 14 May 2001, Alan Cox wrote:
>
> Except that Linus wont hand out major numbers, which means I can't even boot
> simply off such a device. I bet the vendors in question dont think the sun
> shines out of linus backside any more.
Actually, it does. It's just that some people have gotten
On Mon, 14 May 2001, Alan Cox wrote:
>
> Yet another 2.5 project. If Linus wants to go play with name driven devices
> and you want to help him great, but if he'd care to put out
> linux-2.5.0.tar.gz _before_ starting that would be good for all of us
ACK! .. 2.5?? .. gawd .. I just installed
On Mon, 14 May 2001, Rik van Riel wrote:
> It would be cool if one of you two could update the docs ;)
OK, here is my attempt, as a patch to Configure.help in 2.4.5-pre1. I
hope it is clear, accurate, and not too long-winded, and that my mailer
does not munge patches.
Cheers,
Wayne
---
On Mon, 14 May 2001, Alan Cox wrote:
> Subject: Re: LANANA: To Pending Device Number Registrants
>
> > Would you mind demonstrating such wonder? Old devices are still there,
> > AFAICS. Ext2 (reiserfs, devfs, abortion-of-your-choice-fs) still has
> > the ability to create device nodes for them.
While reading the "getting fs access events" thread I remembered
something which I've been meaning to look at for ages.
[some history]
I don't trust programs which dump file systems by reading the data
directly from the block device (I'm never sure that they get things
right). I prefer to do
On Mon, 14 May 2001, Richard Gooch wrote:
>
> Is there some fundamental reason why a buffer cache can't ever be
> fast?
Yes.
Or rather, there is a fundamental reason why we must NEVER EVER look at
the buffer cache: it is not coherent with the page cache.
And keeping it coherent would be
On Mon, 14 May 2001, Andi Kleen wrote:
[.]
> Packets are dropped when a device queue
> fills, and when one sender is much faster than the other the faster sender
> often wins the race, while the packets of the slower one get dropped.
[.]
Speaking of queues on routers/servers, does
Mihai Moldovanu wrote:
>
> In 2.4.2 the driver for this was e100.o
> Can someOne tell me wich one is in 2.4.4 ?
You need to download that from Intel, it's not in the official kernel
and never has been. "eepro100" is the in-kernel driver for those series
of cards.
--
Jeff Garzik | Game
In 2.4.2 the driver for this was e100.o
Can someOne tell me wich one is in 2.4.4 ?
--
MihaiM
-
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
On Mon, 14 May 2001, Jeff Golds wrote:
> Oh I get it NOW. "Off" means the docs are just plain "off".
It is ... "off" means we do 1GB-128MB = 896MB of memory.
It would be cool if one of you two could update the docs ;)
regards,
Rik
--
Virtual memory is like a game you can't win;
However,
You can get a working tree from www.fsmlabs.com/linuxppcbk.html or just
apply the patches in ftp.kernel.org/pub/linux/kernel/people/cort/
If you have any trouble with that, let me know.
} [1.] One line summary of the problem:
} 2.4.4 fails to compile for G3 ppc
}
} [2.] Full description of
Brian Gerst wrote:
> >
> > It seems obvious once you know why the limits are there. The 1 GB
> > limit (actually 1024-128 MB = 896 MB) is a software limit; the 4 GB
> > and 64 GB limits are hardware limits and are exact.
>
> Even with the 4GB and 64GB options, some physical address space has to
"H. Peter Anvin" wrote:
>
> Followup to: <[EMAIL PROTECTED]>
> By author:Rik van Riel <[EMAIL PROTECTED]>
> In newsgroup: linux.dev.kernel
> >
> > On Mon, 14 May 2001, Wayne Whitney wrote:
> > > In mailing-lists.linux-kernel, you wrote:
> > >
> > > > You need to compile highmem support into
On Tuesday 15 May 2001 01:19, Richard Gooch wrote:
> Linus Torvalds writes:
> > On Sun, 13 May 2001, Richard Gooch wrote:
> > > So, why can't the page cache check if a block is in the buffer
> > > cache?
> >
> > Because it would make the damn thing slower.
> >
> > The whole point of the page
I cannot for the life of me get LFS working.
I have recompiled the glibc rpm (the 2.2.1 one)
for i686 and installed it. I have recompiled
fileutils against that glibc. It still tells
me that the file is too large when I do a
dd if=/dev/zero of=bigfile bs=8192
it stops at 2.0GB (ls -lh). What
Again battling with my SDT-9000, tonight first experiment was:
- Moderately huge file (339443712 bytes). Obtained cat'ing some large
tar.bz2, so essentially 'random data'
- Fixed block size (dd bs=32KB, mt bs=512=default)
- HW data compression at default (enabled)
- Variable machine load
Rik van Riel wrote:
> Where did you get the mythical "1GB" option?
>
> Last I looked we had "off", "4GB" and "64GB" ;)
We do .. under 2.4.x
In 2.2.x we have 1 Gb and 2 GB ... 2.2.19 at least
--
=
Mohammad A. Haque
On Sun, May 13, 2001 at 01:28:06PM -0400, Jeff Garzik wrote:
> For those of you with Via interrupting routing issues (or
> interrupt-not-being-delivered issues, etc), please try out this patch
> and let me know if it fixes things. It originates from a tip from
> Adrian Cox... thanks Adrian!
On Mon, 14 May 2001 23:55:37 +0100 (BST),
Alan Cox <[EMAIL PROTECTED]> wrote:
>> > And lilo ?
>Also hdparm
>raidtools
>psmisc
>mtools
>mt-st
>gpm
>joystick
kmod, /etc/modules.conf:
alias block-major-what-random-number-did-the-kernel-pick-this-time driver_name
-
To unsubscribe from this list:
Rik van Riel wrote:
>
> On Mon, 14 May 2001, Jeff Golds wrote:
>
> > Ahh, it's totally obvious. 1 GB option = 890 MB, 4 GB option =
> > 4GB. Can I assume a linear relation and get 66.2 MB when I
> > select the 64 MB option?
>
> Where did you get the mythical "1GB" option?
>
> Last I looked
On Mon, 14 May 2001, Marcelo Tosatti wrote:
> On Mon, 14 May 2001, Rik van Riel wrote:
>
> > + /* XXX: dynamic free target is complicated and may be wrong... */
> > int freetarget = freepages.high + inactive_target / 3;
>
> I think its better if we just remove " + inactive_target / 3" here
On Mon, 14 May 2001, Jeff Golds wrote:
> Ahh, it's totally obvious. 1 GB option = 890 MB, 4 GB option =
> 4GB. Can I assume a linear relation and get 66.2 MB when I
> select the 64 MB option?
Where did you get the mythical "1GB" option?
Last I looked we had "off", "4GB" and "64GB" ;)
On Mon, 14 May 2001, Alan Cox wrote:
> > I've been doubting whether to work on both the -ac kernels
> > and the -linus tree, but this is a pretty good argument for
> > sticking with -ac and just ignoring the -linus tree...
>
> Time will make that decision. Linus kindly gave us all the power
> to
Followup to: <[EMAIL PROTECTED]>
By author:Rik van Riel <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> On Mon, 14 May 2001, Wayne Whitney wrote:
> > In mailing-lists.linux-kernel, you wrote:
> >
> > > You need to compile highmem support into the kernel if you want to
> > > use more
On Mon, 14 May 2001, Ben LaHaise wrote:
> Hey folks,
Hi.
>
> The patch below consists of 3 seperate fixes for helping remove the
> deadlocks present in current kernels with respect to highmem systems.
> Each fix is to a seperate file, so please accept/reject as such.
> The third patch
On Mon, 14 May 2001, Rik van Riel wrote:
> Hi Linus,
>
> the following patch does:
> pg_data_t *pgdat = pgdat_list;
> int sum = 0;
> int freeable = nr_free_pages() + nr_inactive_clean_pages();
> + /* XXX: dynamic free target is complicated and may be wrong... */
>
[EMAIL PROTECTED] wrote:
>
> Hello!
>
> > Note that using dev->name during probe was always incorrect. Think
> > about the error case:
> ...
> > So, using interface name in this manner was always buggy because it
> > conveys no useful information to the user.
>
> I used to think about cases
> Why can't we configure this in user space? I think of something like
> /etc/major-numbers. We could then tell the kernel at module load time what
> major number to use for a given driver.
We've got one of those lists. H Peter Anvin maintains it.
Don't get me wrong - if in 2.5.x someone can
On Mon, May 14, 2001 at 11:21:00PM +0100, Alan Cox wrote:
> You can make it a string if you like but at the end of the day
> has to be an opaque handle. For constant devices it also has to be
> a constant name. Otherwise the /dev file I archived with the corporate
>
Andi Kleen writes:
> On Mon, May 14, 2001 at 01:29:51PM -0700, Linus Torvalds wrote:
> > Big device numbers are _not_ a solution. I will accept a 32-bit one, but
> > no more, and I will _not_ accept a "manage by hand" approach any more. The
> > time has long since come to say "No". Which I've
On Sun, 13 May 2001, Linus Torvalds wrote:
>
> On Sun, 13 May 2001, Rik van Riel wrote:
> >
> > This means that the swapin path (and the same path for
> > other pagecache pages) doesn't take the page lock and
> > the page lock doesn't protect us from other people using
> > the page while we
Hey folks,
The patch below consists of 3 seperate fixes for helping remove the
deadlocks present in current kernels with respect to highmem systems.
Each fix is to a seperate file, so please accept/reject as such.
The first patch adding __GFP_FAIL to GFP_BUFFER is needed to fix a
livelock
Alan Cox writes:
> > Oh, _that_ one. pass rootname=driver!name (or whatever syntax
> > you prefer) to the kernel and call do_mount() instead of sys_mknod() in
> > prepare_namespace() (rootfs patch). BFD.
>
> Yet another 2.5 project. If Linus wants to go play with name driven
> devices and you
Jeff Golds wrote:
>
> Rik van Riel wrote:
> >
> > On Mon, 14 May 2001, Wayne Whitney wrote:
> > > In mailing-lists.linux-kernel, you wrote:
> > >
> > > > You need to compile highmem support into the kernel if you want to
> > > > use more than 890 MB of RAM, set it to maximum 4GB for best
> > > >
Alan Cox writes:
> > > (c) does not require devfs. most distros ship without it afaik, and
> > > switching to it is not an overnight process, and requires devfsd to be
> > > useful in the real world.
> > >
> >
> > It does, however, not manage permissions, nor does it provide for a sane
> >
Rik van Riel wrote:
>
> On Mon, 14 May 2001, Wayne Whitney wrote:
> > In mailing-lists.linux-kernel, you wrote:
> >
> > > You need to compile highmem support into the kernel if you want to
> > > use more than 890 MB of RAM, set it to maximum 4GB for best
> > > performance...
> >
> > On a similar
> > 323
> > Also hdparm
> > raidtools
> > psmisc
> > mtools
> > mt-st
> > gpm
> > joystick
>
> so we now have a list of stuff that needs to be fixed 8)
> or at least, a cross section sampling of stuff to design a new API for.
Yes. Most of it actually uses the major stuff to answer the
On Mon, 14 May 2001, Alan Cox wrote:
> grep MAJOR lilo-21.4.4/*|wc -l
> 323
/me looks and barfs.
Alan, had you actually looked at it? It will require massive changes
whenever you introduce new major. And most of such areas are stuff
that doesn't matter for new devices anyway - geometry,
On Mon, 14 May 2001, Alan Cox wrote:
> > Oh, _that_ one. pass rootname=driver!name (or whatever syntax
> > you prefer) to the kernel and call do_mount() instead of sys_mknod() in
> > prepare_namespace() (rootfs patch). BFD.
>
> Yet another 2.5 project. If Linus wants to go play with name
On Mon, 14 May 2001, Wayne Whitney wrote:
> In mailing-lists.linux-kernel, you wrote:
>
> > You need to compile highmem support into the kernel if you want to
> > use more than 890 MB of RAM, set it to maximum 4GB for best
> > performance...
>
> On a similar note, what is the maximum physical
> > it to a device number at /sbin/lilo time. An idiotic practice on the
> > part of LILO, in my opinion, that ought to have been fixed a long time
> > ago.
>
> That's why you want mount-root-by-partition-label, not by device
Which in itself adds the 'and how does the label tell me what
Before merging both hard disks I saw each of them as a separate SCSI
device, at boot time and when the system booted up. After building the
RAID1, when the system boots I only see one RAID device recognized, and so
do I when linux recognizes it.
[root@lala log]# cat /proc/scsi/dpt_i2o/0
Vendor:
In article <[EMAIL PROTECTED]> you wrote:
> That's not the issue. LILO takes whatever you pass to root= and converts
> it to a device number at /sbin/lilo time. An idiotic practice on the
> part of LILO, in my opinion, that ought to have been fixed a long time
> ago.
That's why you want
Linus Torvalds writes:
>
>
> On Sun, 13 May 2001, Richard Gooch wrote:
> >
> > OK, provided the prefetch will queue up a large number of requests
> > before starting the I/O. If there was a way of controlling when the
> > I/O actually starts (say by having a START flag), that would be ideal,
>
On Mon, 14 May 2001, Alan Cox wrote:
> grep MAJOR lilo-21.4.4/*|wc -l
> 323
> Also hdparm
> raidtools
> psmisc
> mtools
> mt-st
> gpm
> joystick
so we now have a list of stuff that needs to be fixed 8)
or at least, a cross section sampling of stuff to design a new API for.
-Dan
-
To
On Mon, 14 May 2001, H. Peter Anvin wrote:
> > LILO uses BIOS, for fsck sake. It couldn't care less for device numbers
> > on the kernel side. Ask Andries how much do they have in common with
> > BIOS drive numbers.
> >
>
> That's not the issue. LILO takes whatever you pass to root= and
Hi,
I built a nice mp3 player out of a AMD 486-DX133 and a soundblaster
es1371. I always used 2.2.16 and it worked properly. Due to several
reasons I want to switch to 2.4, so I tried my luck with 2.4.4-ac6.
Basically it works but the sound gets interrupted (around 0.5 - 5seconds
silence) from
> > And lilo ?
>
> LILO uses BIOS, for fsck sake. It couldn't care less for device numbers
> on the kernel side. Ask Andries how much do they have in common with
> BIOS drive numbers.
grep MAJOR lilo-21.4.4/*|wc -l
323
Also hdparm
raidtools
psmisc
mtools
mt-st
gpm
joystick
and that is a
> Oh, _that_ one. pass rootname=driver!name (or whatever syntax
> you prefer) to the kernel and call do_mount() instead of sys_mknod() in
> prepare_namespace() (rootfs patch). BFD.
Yet another 2.5 project. If Linus wants to go play with name driven devices
and you want to help him great, but if
In mailing-lists.linux-kernel, you wrote:
> You need to compile highmem support into the kernel if you want to
> use more than 890 MB of RAM, set it to maximum 4GB for best
> performance...
On a similar note, what is the maximum physical memory supported by
the 4GB option?
Cheers, Wayne
-
To
On Mon, 14 May 2001, Alan Cox wrote:
> > > Except that Linus wont hand out major numbers, which means I can't even boot
> > > simply off such a device. I bet the vendors in question dont think the sun
> > > shines out of linus backside any more.
> >
> > Not really. Special-casing for mounting
> > Except that Linus wont hand out major numbers, which means I can't even boot
> > simply off such a device. I bet the vendors in question dont think the sun
> > shines out of linus backside any more.
>
> Not really. Special-casing for mounting root is trivially solvable. BTDT,
> and you've
Alexander Viro wrote:
>
> On Mon, 14 May 2001, Alan Cox wrote:
>
> > > > Except that Linus wont hand out major numbers, which means I can't even boot
> > > > simply off such a device. I bet the vendors in question dont think the sun
> > > > shines out of linus backside any more.
> > >
> > > Not
On Mon, 14 May 2001, Alan Cox wrote:
> > Would you mind demonstrating such wonder? Old devices are still there,
> > AFAICS. Ext2 (reiserfs, devfs, abortion-of-your-choice-fs) still has
> > the ability to create device nodes for them.
>
> Except that Linus wont hand out major numbers, which
Alexander Viro wrote:
>
> On Mon, 14 May 2001, H. Peter Anvin wrote:
>
> > Correct. At least at one time it used the offset of the directory entry
> > when that particular inode was last "seen" by the kernel... meaning that
> > when it finally dropped out of the inode cache, it would change
What makes you think /dev/sda is the raid? For me cat /proc/scsi/scsi
lists all 4 drives which, to me, implies that it is raw.
fdisk could not partition the raid by default. I needed to use sfdisk the
first time. After that fdisk worked fine.
If I have both modules loaded I can mount
On Monday 14 May 2001 22:04, Andreas Dilger wrote:
> Daniel writes:
> > I was originally thinking we should give the admin the ability to
> > create a nonindexed directory if desired, and that's how it used to
> > be before we changed the setting of INDEX_FL from directory
> > creation time to
On Monday 14 May 2001 22:04, Andreas Dilger wrote:
> Maybe we can have a "noindex" mount option for this?
We need that regardless, I just keep forgetting to put it in. I assume
the semantics are obvious: no new indexes are created but existing ones
are maintained. I.e., -o noindex does not
> Would you mind demonstrating such wonder? Old devices are still there,
> AFAICS. Ext2 (reiserfs, devfs, abortion-of-your-choice-fs) still has
> the ability to create device nodes for them.
Except that Linus wont hand out major numbers, which means I can't even boot
simply off such a device. I
> buz.c references KMALLOC_MAXSIZE which appears to be no longer defined.
> In order to build it, I've had to re-add this define to slab.h.
>
> Saw it in 2.4.3. Still in 2.4.4
buz.c is dead. Use the -ac kernel and the ZR36067 driver
-
To unsubscribe from this list: send the line "unsubscribe
> It's not so much about hardcoding the names as hardcoding the *STRUCTURE*
> of the names. For example, the current devfs has /dev/misc/* which is
> completely bogus -- it exposes an implementation detail (using the
The fact kernel space touches on naming directly is itself bogus. devfsd doing
On Mon, May 14, 2001 at 03:50:01PM -0400, Stuart MacDonald wrote:
> What version of serial.c? I'm assuming 5.05.
Serial driver version 5.05a (2001-03-20) with MANY_PORTS SHARE_IRQ
SERIAL_PCI enabled
> Define "go kablooey". We haven't noticed any problems, and we supplied
> this bit of code.
[EMAIL PROTECTED] wrote on 11.05.01 in <[EMAIL PROTECTED]>:
> I think man is the best help system ever devised. (The GNU Info system,
> however, is the spawn of Satan. :-)
Both have good and bad parts. HTML and PDF are yet other such candidates.
Something better is needed, but no two people
buz.c references KMALLOC_MAXSIZE which appears to be no longer defined.
In order to build it, I've had to re-add this define to slab.h.
Saw it in 2.4.3. Still in 2.4.4
sorry new to this list.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Mon, 14 May 2001, Alan Cox wrote:
> Abstract device file systems are beautiful concepts but they don't solve
> the device name space problem and they introduce hideous incompatibilities
> with existing software.
let me get it straight. You are talking about software that would be
On Monday 14 May 2001 20:33, Andreas Dilger wrote:
> Daniel, you write:
> > Now, if the check routine tells us how much good data it found we
> > could use that to set a limit for the dirent scan, thus keeping the
> > same robustness as the old code but without having all the checks
> > in the
Jesper Juhl ([EMAIL PROTECTED]) said:
> I have made a patch against 2.4.4-ac8 that makes the change, it is
> below. I guess someone more knowledgeable than me can probably see if
> this is correct. If this is completely bogus, then please just disregard
> this email.
Yup, it's right. My bad.
> > Then When I tried to fdisk /dev/sda (/dev/sda is a RAID1 of two
> > Quantum disks) syslog shows this:
>
> is /dev/sda the raid or the disks raw ?
/dev/sda is the RAID1
> > So, I don't know if I'm doing something wrong or what, but I haven't been
> > able to get it working on 2.4.4 yet...
On Mon, 14 May 2001, H. Peter Anvin wrote:
> Correct. At least at one time it used the offset of the directory entry
> when that particular inode was last "seen" by the kernel... meaning that
> when it finally dropped out of the inode cache, it would change inode
> numbers. I thought that
On Mon, May 14, 2001 at 04:15:12PM -0500, Samuel Meder wrote:
> I'm seeing a similar effect myself. When I use all my available sdsl
> bandwidth (say doing a bulk data transfer), DNS lookups will often
> time out. This is with the default buffer settings/2.4.4.
The problem is that the DNS
Hi,
This patch renames some PCI_IDS in net drivers to use namespace from
pci_ids.h.
Also the "__{dev,}initdata" variables in pcnet32.c put together.
It seems that the "section type conflict" in pcnet32.c some -ac kernels ago
was caused by __initdata variables not declared together (some public
On Monday May 14, [EMAIL PROTECTED] wrote:
> > This means that we need some analogue to {get,put}_unnamed_dev that
> > manages a range of dynamically allocated majors.
> > Is there such a beast already, or does someone need to write it?
> > What range(s) should be used for block devices?
> >
>
> May 14 16:29:12 lala kernel: PARAMS_GET - Error:
> May 14 16:29:12 lala kernel: ErrorInfoSize = 0x01, BlockStatus = 0x08,
> BlockSize = 0x0002
> May 14 16:29:12 lala kernel: PARAMS_GET - Error:
> May 14 16:29:12 lala kernel: ErrorInfoSize = 0x01, BlockStatus = 0x08,
> BlockSize = 0x0002
On Monday May 14, [EMAIL PROTECTED] wrote:
> Neil Brown wrote:
> > So I need a major number - to give to devfs_register_blkdev at least.
> > You don't want me to have a hardcoded one (which is fine) so I need a
> > dynamically allocated one - yes?
> >
> > This means that we need some analogue to
On Mon, 14 May 2001, Alan Cox wrote:
> > well, I applied 2.4.4ac8 (I couldn't find ac9) and I still have only
> > errors when recognizing the hardware. The long waiting is gone. I will try
> > to send the messages somehow. They were not saved on log files because it
> > couldn't mount the
> I've been doubting whether to work on both the -ac kernels
> and the -linus tree, but this is a pretty good argument for
> sticking with -ac and just ignoring the -linus tree...
Time will make that decision. Linus kindly gave us all the power to vote with
our feet. One thing I absolutely
> I'm curious about this effect so I've been trying to find information
> on this and while I can find lots of information on the Ethernet
> capture effect there doesn't seem to be anything on the TCP capture
> effect. Could someone point me at an explanation of this effect?
it is exactly the
Neil Brown wrote:
> So I need a major number - to give to devfs_register_blkdev at least.
> You don't want me to have a hardcoded one (which is fine) so I need a
> dynamically allocated one - yes?
>
> This means that we need some analogue to {get,put}_unnamed_dev that
> manages a range of
> This means that we need some analogue to {get,put}_unnamed_dev that
> manages a range of dynamically allocated majors.
> Is there such a beast already, or does someone need to write it?
> What range(s) should be used for block devices?
>
> Am I missing something obvious here?
Obvious
Alexander Viro wrote:
>
> On Mon, 14 May 2001, Andreas Dilger wrote:
>
> > Just to clarify, this means that the "inode numbers" reported by an
> > msdos filesystem are a function of the disk-layout itself (i.e. they
> > are determined at mount time), and not numbers created when the file
> > is
> Big device numbers are _not_ a solution. I will accept a 32-bit one, but
> no more, and I will _not_ accept a "manage by hand" approach any more. The
> time has long since come to say "No". Which I've done. If you can't make
> it manage the thing automatically with a script, you won't get a
> Note also that persistence of permissions and hardcoded in-kernel naming
> is a problem throughout proc... It's not unique to in-driver
> filesystems.
And the /proc namespace is a walking testimony to why numbers are not the
primarily problem in /dev space and tidyness
-
To unsubscribe from
On Mon, 14 May 2001, Linus Torvalds wrote:
> End of discussion.
I've been doubting whether to work on both the -ac kernels
and the -linus tree, but this is a pretty good argument for
sticking with -ac and just ignoring the -linus tree...
Lets see what happens...
regards,
Rik
--
Linux MM
On Mon, 14 May 2001, Andreas Dilger wrote:
> Just to clarify, this means that the "inode numbers" reported by an
> msdos filesystem are a function of the disk-layout itself (i.e. they
> are determined at mount time), and not numbers created when the file
> is first accessed (AFAIK).
Wrong.
On Mon, May 14, 2001 at 01:29:51PM -0700, Linus Torvalds wrote:
> Big device numbers are _not_ a solution. I will accept a 32-bit one, but
> no more, and I will _not_ accept a "manage by hand" approach any more. The
> time has long since come to say "No". Which I've done. If you can't make
> it
On Thu, May 10, 2001 at 05:58:21PM +0600, Anuradha Ratnaweera wrote:
> Date: Thu, 10 May 2001 17:58:21 +0600 (LKT)
> From: Anuradha Ratnaweera <[EMAIL PROTECTED]>
> To: Russell King <[EMAIL PROTECTED]>
> cc: Duncan Gauld <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Subject: Re: Possible
1 - 100 of 469 matches
Mail list logo
