rdunlap wrote:
Alan-
Here's a patch to 2.2.19-pre7 that is essentially a backport of the
2.4.0 gate-A20 code.
This speeds up booting on my fast-A20 board (Celeron 500 MHz, no KBC)
from 2 min:15 seconds to too small to measure by my wrist watch.
Kai, you reported that your system was
"Dunlap, Randy" wrote:
a. The BIOS isn't required to have int. 0x15, AH=0x2401 [Appx. A],
but that is handled by your patch.
Idiots. This should be required and be a null function; likewise
AH=0x2400. The only thing that the current spec means is that
b. The BIOS isn't required to
Followup to: [EMAIL PROTECTED]
By author:=?iso-8859-1?Q?Jakob_=D8stergaard?= [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
On most processors 2 is slower than *4.
That's a funny statement. Which processors do you include in "most"?
That has not been my experience.
It's outright
"Dunlap, Randy" wrote:
I'm not sure about this, but I'm wondering if the
Fixed (as in Static) ACPI Description Table (FADT)
can indicate that the platform is a legacy-free system.
Parsing ACPI is a nightmare on steroids. That is just Not An Option[TM]
in a 10K bootstrap routine.
I think the way to go is to do the INT 15-first; possibly augmented with
a "test before even doing INT 15"...
-hpa
--
[EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To
Followup to: [EMAIL PROTECTED]
By author:"David S. Miller" [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
Lars Marowsky-Bree writes:
This just goes on to show that khttpd is unnecessary kernel bloat
and can be "just as well" handled by a userspace application, minus
some rather
[EMAIL PROTECTED] wrote:
The signature on man-pages-1.34.tar.gz is bad:
Hmm, thought I had corrected that already.
Is it correct now?
Andries
Because an updated signature has the same timestamp and size, it can take
up to 24 hours for it to hit ftp.kernel.org, and even longer to
Matti Aarnio wrote:
On Fri, Jan 12, 2001 at 12:23:48PM -0800, H. Peter Anvin wrote:
[EMAIL PROTECTED] wrote:
The signature on man-pages-1.34.tar.gz is bad:
Hmm, thought I had corrected that already.
Is it correct now?
Andries
Because an updated signature has the same
"Maciej W. Rozycki" wrote:
On Wed, 10 Jan 2001, H. Peter Anvin wrote:
URRRK. I get a feeling these specs are either there to make life extra
difficult for programmers, because the people that design them are too
stupid to tie their own shoes, or because they want not
"Albert D. Cahalan" wrote:
It looks like we let Microsoft fill the design guide void.
If you were to write "PC DESIGN GUIDE - For the Linux Operating
System" and a pile of test code, then there would be an
alternative to point people at.
Complaining is pretty useless.
I was thinking
Followup to: [EMAIL PROTECTED]
By author:J Sloan [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
Linus Torvalds wrote:
Of course, you may be right on wuftpd. It obviously wasn't designed with
security in mind, other alternatives may be better.
I run proftpd on all my ftp servers
Followup to: [EMAIL PROTECTED]
By author:Matti Aarnio [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
One thing about 'sendfile' (and likely 'sendpath') is that
current (hammered into running binaries - unchangeable)
syscalls support only up to 2GB files at 32 bit
Hugh Dickins wrote:
That's how "notsc" used to behave, but since 2.4.0-test11
"notsc" has left "tsc" in /proc/cpuinfo. setup.c has a bogus
"#ifdef CONFIG_TSC" which should be "#ifndef CONFIG_X86_TSC".
HPA, Maciej and I discussed that around 5 Dec 2000; but HPA
was of Andrea's
"Maciej W. Rozycki" wrote:
On Mon, 15 Jan 2001, H. Peter Anvin wrote:
I would personally prefer to export the global flags separately from the
per-CPU flags. Not only is it more correct, it would help catch these
kinds of bugs!!!
That's what I am going to do. Basically
Followup to: [EMAIL PROTECTED]
By author:Linus Torvalds [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
On Mon, 15 Jan 2001, Tobias Ringstrom wrote:
Last time I checked this was issued for perfectly known and valid bridges
that advertice no IO resources. Isn't it a bit silly to
Followup to: [EMAIL PROTECTED]
By author:"Maciej W. Rozycki" [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
On Mon, 15 Jan 2001, H. Peter Anvin wrote:
Right, but I'd also like to see the global flags exported explicitly to
/proc/cpuinfo.
That's desirable, but how wo
Andre Hedrick wrote:
HPA,
Thoughts on granting all block subsystems a general access misc-char minor
to do special service access that can not be down to a given device if it
is open. There are some things you can not do to a device if you are
using its device-point to gain entry. Also
Andre Hedrick wrote:
On Sat, 20 Jan 2001, H. Peter Anvin wrote:
Andre Hedrick wrote:
HPA,
Thoughts on granting all block subsystems a general access misc-char minor
to do special service access that can not be down to a given device if it
is open. There are some things
Andre Hedrick wrote:
Hi Peter,
Regardless if we rip out the entire rule of majors for dev_t, will there
be a service dummy driver to various block-devices? There is a real need
for this if we are going to get full control of the hardware by indirect
access obtain the functionality that
Followup to: [EMAIL PROTECTED]
By author:Andrew Clausen [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
Apart from
that, the kernel couldn't care. You could set all your Ext2 partitions
as ID 82, your swap as ID 83 and Linux would carry on as if nothing had
changed.
Exactly.
Andreas Dilger wrote:
H. Peter Anvin writes:
We have:
0x82 - Linux swap
0x83 - Linux filesystem
0x85 - Linux extended partition (yes, this one does matter!)
There seems to be some value in having a different value for swap. It
lets an automatic program find
Followup to: [EMAIL PROTECTED]
By author:[EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
That is what I was guessing. But insmod does not need all symbols
present in the .o.
I need to do this because when I release the driver to the customer,
I don't want them to be aware of some of
Followup to: [EMAIL PROTECTED]
By author:"Ian S. Nelson" [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
I'm curious. Why does Linux make that friendly 98/9a/88 looking
postcode pattern when it's running? DOS and DOS95 don't do that.
I'm begining to feel like I can tell the system
Followup to: [EMAIL PROTECTED]
By author:Mikael Pettersson [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
Before people get too exited about the x86 Page Attribute Table ...
Does Linux use mode B (CR4.PSE=1) or mode C (CR4.PAE=1) paging?
If so, known P6 errata must be taken into
Matthew Dharm wrote:
It occurs to me that it might be a good idea to pick a different port for
these things. I know a lot of people who want to use port 80h for
debugging data, especially in embedded x86 systems.
Find a safe port, make sure it is tested the hell out of, and we'll
Matthew Dharm wrote:
Isn't that always the way in the Open Source world? :)
Seriously, tho... does anyone have some list of who is using what ports?
At least, in general?
There is one included in Ralf Brown's Interrupt List. No list you're
going to find is going to be complete, though.
"Richard B. Johnson" wrote:
On Thu, 25 Jan 2001, H. Peter Anvin wrote:
Matthew Dharm wrote:
It occurs to me that it might be a good idea to pick a different port for
these things. I know a lot of people who want to use port 80h for
debugging data, especially in em
Followup to: [EMAIL PROTECTED]
By author:Jeremy Hansen [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
Just curious if others have noticed that hotmail is unable to deal with
ECN and wondering if this is a standard that should be encouraged, as in
should I tell hotmail that perhaps they
"Richard B. Johnson" wrote:
I will change the port on my machines and run them for a week. I
don't have any DEC Rainbows or other such. Yes, I know Linux will
not run on a '286.
Since 0x19 is a hardware register in a DMA controller, specifically
called a "scratch" register, it is
"David S. Miller" wrote:
Secondly, the RFCs are pretty clear that the bits in question used for
ECN are _reserved_ and to be ignored by implementations. That means
to not be interpreted, and more importantly not used to discard
packets.
Last I communicated with them, I looked for a
"Adam J. Richter" wrote:
I am surprised that anyone is seriously considering denying
service to sites that do not implement an _experimental_ facility
and have firewalls that try to play things safe by dropping packets
which have 1's in bit positions that in the RFC "must be zero."
"David S. Miller" wrote:
H. Peter Anvin writes:
Last I communicated with them, I looked for a reference like that in the
standards RFCs so I could quote chapter and verse at the Hotmail people,
but I couldn't find it.
RFC793, where is lists the unused flag bits as
Dominik Kubla wrote:
On Fri, Jan 26, 2001 at 04:27:07PM +0100, Jamie Lokier wrote:
...
Yeah, Apache and Samba establish _outgoing_ connections with fixed
source ports Not!
Oops! Of course. Brain-damage on my part. Now where is that dammned
brown paper bag...
ftpd and sshd do,
"David S. Miller" wrote:
It says "reserved for future use, must be zero".
I think the descrepency (and thus what the firewalls are doing) comes
from the ambiguous "must be zero". I cannot fathom the RFC authors
meaning this to be anything other than "must be set to zero by current
Rogier Wolff wrote:
H. Peter Anvin wrote:
Followup to: [EMAIL PROTECTED]
By author:"Ian S. Nelson" [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
I'm curious. Why does Linux make that friendly 98/9a/88 looking
postcode pattern when it's running? DOS and DOS9
Rogier Wolff wrote:
You seem to state that if you want POST codes, you should find a
different port, modify the code, test the hell out of it, and then
submit the patch.
That is NOT the right way to go about this: Port 0x80 is RESERVED for
POST usage, that's why it's always free. If
Rogier Wolff wrote:
Ok. I've thought about it some more, but I don't care enough about
this issue to do the painstaking legwork: I don't have one of those
POST-code indicators on port 0x80.
I've made the "pause" in outb_p just a few (*) ns slower, because it
now loads a variable before
Followup to: [EMAIL PROTECTED]
By author:Thunder from the hill [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
A file-system without a lost+found directory is like love without sex.
You mean, possible but leaving you unsatisfied? Well, I think a file
system without a lost+found is a
Pavel Machek wrote:
And you're still overwriting the POST value written by the BIOS.
So save value from bios at initial boot ;-).
Pavel
Write-only register.
-hpa
--
[EMAIL PROTECTED] at work, [EMAIL PROTECTED] in
Followup to: [EMAIL PROTECTED]
By author:"Michael B. Trausch" [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
On Mon, 29 Jan 2001, Thunder from the hill wrote:
Don't they understand that Linux is actually a system that is growing to
be very popular?
That's why they ignore and
"Michael B. Trausch" wrote:
On 29 Jan 2001, H. Peter Anvin wrote:
He's keeping in mind who owns Hotmail. However, I think that's unfair
to the Hotmail guys; all the ones I have ever spoken with have been
very professional and genuinely concerned with standards compliance.
Followup to: [EMAIL PROTECTED]
By author:Igmar Palsenberg [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
Yes. First program to run get PID 1.
Solution : fork() in init and load the modules in the child.
Or finish your script with "exec init".
-hpa
--
[EMAIL PROTECTED]
Followup to: [EMAIL PROTECTED]
By author:Richard B. Johnson [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
I noticed that my favorite errno has now gotten trashed by
the newer 'C' runtime libraries.
ENOTTY has been for ages, Not a typewriter.
It's now been changed to Inappropriate
Followup to: [EMAIL PROTECTED]
By author:Edgar Toernig [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
I think you have a wrong idea why the ECC is there. ECC deals with
the inherit shortcommings of DRAM.
DRAMs are not perfect. They have a probability to lose a bit.
Normally this
[EMAIL PROTECTED] wrote:
On 05/10/2001 at 05:38:32 PM [EMAIL PROTECTED] (H. Peter Anvin) wrote:
Sounds like someone has just clarified what the heck it means. tty
and typewriter aren't exactly the same thing (even though tty
stands for teletypewriter it has come to mean something
Followup to: [EMAIL PROTECTED]
By author:Alan Cox [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
A new format is fine but import old ones properly. And if you do a new format
stop using kdev_t on disk - it will change size soon
Not to mention that it might end up being a pointer, or
Followup to: [EMAIL PROTECTED]
By author:Blesson Paul [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
Hi J
You misunderstood my question. Let take an example.
Let I have a msdos partition. No msdos files has inode numbers, right. Let I
mount that msdos partition. Then
Followup to: [EMAIL PROTECTED]
By author:Alan Cox [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
20:12 is more common
Which is major, which is minor?
20bit major
Surely you're jesting?
12 bit major, 20 bit minor is the only logical split. The need for
minors (think
Followup to: [EMAIL PROTECTED]
By author:Jesse Pollard [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
well... actually it was 6 bit ascii computed from: (char - ' '). Depends
entirely on architecture, and implementation. EBCD/6Bit/7Bit and EBCDIC were
supported on the Honeywell
that to happen.
Please note that this is not my decision (in fact, I have serious
concerns with it.) In particular, /dev namespace coordination still
applies.
Sincerely,
H. Peter Anvin
The Linux Assigned Names and Numbers Authority
-
To unsubscribe from this list: send the line
Jeff Garzik wrote:
H. Peter Anvin wrote:
Linus Torvalds has requested a moratorium on new device number
assignments. His hope is that a new and better method for device space
handing will emerge as a result.
Here's my suggestion for a solution.
Once I work through a bunch of net
Jeff Garzik wrote:
Note also that persistence of permissions and hardcoded in-kernel naming
is a problem throughout proc... It's not unique to in-driver
filesystems.
It's not so much about hardcoding the names as hardcoding the *STRUCTURE*
of the names. For example, the current devfs has
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 first
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 inode
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 than 890 MB 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
be
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= argument through
Followup to: [EMAIL PROTECTED]
By author:mirabilos [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
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
Followup to: [EMAIL PROTECTED]
By author:Sourav Sen [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
But when I boot up that kernel that printk gets executed. While
booting, at least to my knowledge, that part of the code is not supposed
to get executed. Also while the kernel
Linus Torvalds wrote:
But no, I don't actually like sockets all that much myself. They are hard
to use from scripts, and many more people are familiar with open/close and
read/write.
I always thought it was really strange that I couldn't open() a AF_UNIX
socket in order to write() to it
Followup to: [EMAIL PROTECTED]
By author:Alexander Viro [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
UNIX-like ones (and that includes QNX) are easy. HFS is hopeless - it won't
be fixed unless authors will do it. Tigran will probably fix BFS just as a
learning experience ;-) ADFS
Followup to: [EMAIL PROTECTED]
By author:Anton Altaparmakov [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
They shouldn't, but maybe some stupid utility or a typo will do it creating
two incoherent copies of the same block on the device. - Bad Things can
happen.
Can't we simply
Richard Gooch wrote:
Ingo Oeser writes:
On Tue, May 15, 2001 at 08:10:29AM -0700, Linus Torvalds wrote:
and I don't see why we couldn't expose the driver
name for any file descriptor.
Because we dont like to replace:
if (st.device == MAJOR_1)
bla
else if ...
Alexander Viro wrote:
On 15 May 2001, H. Peter Anvin wrote:
isofs wouldn't be too bad as long as struct mapping:struct inode is a
many-to-one mapping.
Erm... What's wrong with inode-u.isofs_i.my_very_own_address_space ?
None whatsoever. The one thing that matters is that noone
James Simmons wrote:
Don't get boxed in by thinking that you only have one fd. Even if you have
only one _device_node_, you can have multiple fd's. In fact, you can, with
the Linux VFS layer, fairly easily do things like
mknod /dev/fd0 c X Y
and then use
fd =
James Simmons wrote:
fd = open(/dev/fd0/colourspace, O_RDWR);
Yipes!! I have to say UNIX has a tendency to teach you ioctl is the only
way. I have never thought outside of the box nor see anyone else in this
manner. This is absolutely brillant!!! I can see alot of possibilties with
Alexander Viro wrote:
None whatsoever. The one thing that matters is that noone starts making
the assumption that mapping-host-i_mapping == mapping.
One actually shouldn't assume that mapping-host is an inode.
What else could it be, since it's a struct inode *? NULL?
-hpa
Alexander Viro wrote:
What else could it be, since it's a struct inode *? NULL?
struct block_device *, for one thing. We'll have to do that as soon
as we do block devices in pagecache.
How would you know what datatype it is? A union? Making struct
block_device * a struct inode * in
Alexander Viro wrote:
On Tue, 15 May 2001, James Simmons wrote:
only one _device_node_, you can have multiple fd's. In fact, you can, with
the Linux VFS layer, fairly easily do things like
mknod /dev/fd0 c X Y
and then use
fd = open(/dev/fd0/colourspace,
Alan Cox wrote:
[ The biggest silliness is this let's try to make the disks appear in the
same order that the BIOS probes them. Now THAT is really stupid, and it
goes on a lot more than I'd ever like to see. ]
RIght - Lilo needs to know but nobody else should except when they need
Tim Fletcher wrote:
It's in, but for some strange reason you have to ask for it explicitly
with the lba32 option.
Because the 32bit bios calls lilo uses in lba32 mode can cause problems
with broken or old bios's hence is defaults to a safe option, and if you
can't boot without it (over
Alexander Viro wrote:
void *.
Look, methods of your address_space certainly know what they hell they
are dealing with. Just as autofs_root_readdir() knows what inode-u.generic_ip
really points to.
Anybody else has no business to care about the contents of -host.
Why do we need a
James Simmons wrote:
Personally, I'd really like to see /dev/ttyS0 be the first detected serial
port on a system, /dev/ttyS1 the second, etc. Currently there are plenty of
different serial hardware with all their own drivers and /dev entries. For
embedded systems with serial consoles,
Alexander Viro wrote:
On Tue, 15 May 2001, Chip Salzenberg wrote:
According to Linus Torvalds:
I don't see why we couldn't expose the driver name for any file
descriptor.
Is it wise to assume that there is only one such name for *any* file
descriptor?
Type of filesystem
Chip Salzenberg wrote:
According to H. Peter Anvin:
A device can inherently belong to multiple device classes, and it
really should be thought of as such.
And then there are layering technologies like LVM and loopback.
They should be included in a discovery, but if you limit yourself
Alan Cox wrote:
Wouldn't it be better just to *try* ioctls and see which ones work and
which ones don't?
1. We have overlaps
1. is of course a problem in itself. Someone who creates overlapping
ioctls should be spanked, hard.
2. I've seen code where people play clever ioctl tricks
Richard Gooch wrote:
Alexander Viro writes:
On Tue, 15 May 2001, Richard Gooch wrote:
Alan Cox writes:
len = readlink (/proc/self/3, buffer, buflen);
if (strcmp (buffer + len - 2, cd) != 0) {
fprintf (stderr, Not a CD-ROM! Bugger
Richard Gooch wrote:
Even if we have per-device filesystems, we are going to have the same
issue, in one form or another. If we have a /devicetype trailing
component added on, then somewhere it has to report CD-ROM or cd
or Compact Disc.
Again, many device types aren't mutually
Albert D. Cahalan wrote:
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
Alan Cox wrote:
1. is of course a problem in itself. Someone who creates overlapping
ioctls should be spanked, hard.
No argument there. But there is no LANANA ioctl body
I though Michael Chastain was maintaining this set. No, we haven't made
it an official LANANA function, mostly
Daniel Phillips wrote:
Sounds like treat it like a file and it acts like a file, treat it
like a directory and it acts like a directory.
The original plan was that you only could indirect through it; not
chdir() for example. One could do the whole enchilada, but then one
would have to
Anton Altaparmakov wrote:
And how are you thinking of this working without introducing new
interfaces if the caches are indeed incoherent? Please correct me if I
understand wrong, but when two caches are incoherent, I thought it means
that the above _would_ screw up unless protected by
Anton Altaparmakov wrote:
True, but I was under the impression that Linus' master plan was that the
two would be in entirely separate name spaces using separate cached copies
of the device blocks.
Nothing was said about the superblock at all.
-hpa
--
[EMAIL PROTECTED] at work,
Richard Gooch wrote:
Geert Uytterhoeven writes:
On Tue, 15 May 2001, Richard Gooch wrote:
Alan Cox writes:
len = readlink (/proc/self/3, buffer, buflen);
if (strcmp (buffer + len - 2, cd) != 0) {
fprintf (stderr, Not a CD-ROM! Bugger off.\n);
Richard Gooch wrote:
H. Peter Anvin writes:
Richard Gooch wrote:
Argh! What I wrote in text is what I meant to say. The code didn't
match. No wonder people seemed to be missing the point. So the line of
code I actually meant was:
if (strcmp (buffer + len - 3, /cd) != 0
Richard Gooch wrote:
Because you are now, once again, tying two things that are
completely and utterly unrelated: device classification and device
name. It breaks every time someone comes out with a new device
which is kind of like an old device, but not really, like
CD-writers
Ingo Oeser wrote:
We do this already with ide-scsi. A device is visible as /dev/hda
and /dev/sda at the same time. Or think IDE-CDRW: /dev/hda,
/dev/sr0 and /dev/sg0.
All at the same time.
... and if you don't know about this funny aliasing, you get screwed.
This is BAD DESIGN, once
Followup to: [EMAIL PROTECTED]
By author:Alexander Viro [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
Well, since all I actually use in the full variant of patch is sys_mknod(),
sys_chdir() and sys_mkdir()... IMO tmpfs is an overkill here. Maybe we
really need minimal rootfs in the
Alexander Viro wrote:
In full variant of patch I don't _have_ mount_root(9). It's done by
mount(2). Period. Initrd or not. Notice that rootfs stays absolute root
forever - it's much more convenient for fs/super.c, since you can get rid
of many kludges that way. So I'm not too happy about
Richard Gooch wrote:
H. Peter Anvin writes:
Ingo Oeser wrote:
We do this already with ide-scsi. A device is visible as /dev/hda
and /dev/sda at the same time. Or think IDE-CDRW: /dev/hda,
/dev/sr0 and /dev/sg0.
All at the same time.
... and if you don't know about
Alan Cox wrote:
Are FireWire (and USB) disks always detected in the same order? Or does it
behave like ADB, where you never know which mouse/keyboard is which
mouse/keyboard?
USB disks are required (haha etc) to have serial numbers. Firewire similarly
has unique disk identifiers.
Richard Gooch wrote:
Erm, let's start again. My central point is that you can use devfs
names to reliably figure out what kind of device a FD is, as a cleaner
alternative to comparing major numbers. Therefore, I'm challenging the
notion that you need to reserve magic major numbers in order
Richard Gooch wrote:
H. Peter Anvin writes:
Richard Gooch wrote:
Erm, let's start again. My central point is that you can use devfs
names to reliably figure out what kind of device a FD is, as a cleaner
alternative to comparing major numbers. Therefore, I'm challenging
Richard Gooch wrote:
OK. How do you figure on dealing with the problem of multiple
high-level drivers talking to the same device? How does sr.o know
that this is also a CD-RW? How does sg.o know that this is also a
tape?
At some point something talks to the device -- in this case, it's
Richard Gooch wrote:
Alan Cox writes:
Argh! What I wrote in text is what I meant to say. The code didn't
match. No wonder people seemed to be missing the point. So the line of
code I actually meant was:
if (strcmp (buffer + len - 3, /cd) != 0) {
Followup to: [EMAIL PROTECTED]
By author:Felix von Leitner [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
I can't copy a file larger than 2 gigs to my vfat partition.
What gives? 2.4.4-ac5 kernel. My cp copies 2 gigs and then aborts.
$ echo foo file_on_vfat_partition
causes
Followup to: [EMAIL PROTECTED]
By author:Tim Hockin [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
The aic7xxx assembler requiring libdb1 is a bungle. Getting the headers
for that right on various distros is not easy. Add to that it requires
YACC, when most people have bison (yes, a
Richard B. Johnson wrote:
I have both. I also have `flex`, but not `lex'. `lex' is a simlink to
flex. What this compile wanted is some header files in expects for
`yacc` that are not present. And they don't come with the `bison`
distribution. Maybe they came with `yacc` years ago? Anyway
Followup to: [EMAIL PROTECTED]
By author:Paul Gortmaker [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
Does there exist an outline (detailed or not) of the boot process from
the point of BIOS bootsector load to when the kernel proper begins
IIRC, there is some useful info
Followup to: [EMAIL PROTECTED]
By author:Martin.Knoblauch [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
Hi,
while trying to enhance a small hardware inventory script, I found that
cpuinfo is missing the details of L1, L2 and L3 size, although they may
be available at boot time.
1 - 100 of 12109 matches
Mail list logo
