OK, chunk #3: beginnings of garbage collection for vfsmounts
and cleanup of do_umount() path.
* kill_super() had always been conditional on the
list_empty(>s_mounts). Check had been pulled inside kill_super(),
if we still have other mounts of that superblock kill_super() simply
Hi All,
I am working with Dawson Engler's meta-compillation group @ Stanford.
In net/wanrouter/wanproc.c the authors check for a bad copy_to_user and
immediately return -EFAULT. However, it is necessary to rollback some
allocated memory. This can leak memory over time, thus leading to
system
Hi everybody,
I'd like to offer my $0.02 to the ongoing discussion.
IIRC we already have some OOB-data channels - ioctl, setsockopt, fcntl ...
to name only a few.
But: we already have a side-band: send with MSG_OOB!
And, as I just saw in the sources, there are some flags free.
So how about
Hi ,
I have a proposition at hand to optimize getting system time by
avoiding
the system call(gettimeofday()) overhead. This can be implemented by
keeping a read-only page of kernel memory mapped into user processes
for reading quickly. A kernel process can keep that page up-to-date.
I
On Wed, 23 May 2001, Edgar Toernig wrote:
> And with special "ctrl" devices (ie /dev/ttyS0 and /dev/ttyS0ctrl):
> This _may_ work for some kind of devices. But serial ports are one
> example where it simply will _not_. It requires that you know the
That's quite funny, you know...
Daniel Phillips wrote:
>
> On Tuesday 22 May 2001 17:24, Oliver Xymoron wrote:
> > On Mon, 21 May 2001, Daniel Phillips wrote:
> > > On Monday 21 May 2001 19:16, Oliver Xymoron wrote:
> > > > What I'd like to see:
> > > >
> > > > - An interface for registering an array of related devices
> > > >
On Wed, 23 May 2001, Andrew Morton wrote:
> Alexander Viro wrote:
> >
> > Locking rules: both require mount_sem and dcache_lock being
> > held by callers.
> >
>
> It would help a lot if locking rules were commented in
> the source, rather than on linux-kernel.
They will change in
Alexander Viro wrote:
>
> Locking rules: both require mount_sem and dcache_lock being
> held by callers.
>
It would help a lot if locking rules were commented in
the source, rather than on linux-kernel.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
OK, here's chunk #2.
* two helper functions added: attach_mnt() and detach_mnt().
attach_mnt() adds leaf to mount tree, detach_mnt() - removes.
Locking rules: both require mount_sem and dcache_lock being
held by callers.
The rest of stuff doing manipulations of
Hi,
I've got a tyan s2520 motherboard (dual PIII + i840) which is having a
problem with APIC errors. I tried running with noapic, but there were
still errors, although fewer. Does anyone have any idea what is going
on? I'm running 2.4.4 and software raid5, which generates a lot of
interrupts.
Linus, since we have sane kill_super() now, the long-promised
cleanups are coming ;-) I'm going to feed them in small incremental
chunks, so if you see something unacceptable - yell. It may turn out
to be a result of bad choice of chunk boundaries, so...
OK, here comes the chunk
Jeff Garzik wrote:
> /dev/sda <-> partition_blkdev <-> /dev/disk{0,1,2,3,4}
> /dev/hda <-> partition_blkdev <-> /dev/disk{5,6,7}
I also point out that handling disk partitions as a -tiny- remapping
blkdev also has the advantage of making it easy to have a single request
device per hardware
> May 23 02:46:24 localhost kernel: Process kudzu (pid: 219,
> stackpage=c7845000)
> May 23 02:46:24 localhost kernel: Stack: c12607e0 0400 0400
> c73aa000 c122a060 c122a05c c122a058 c88fbb20
> May 23 02:46:24 localhost kernel:03f1 03f1 c014ab80
> c73aa3f1 c7845f9c
Linus Torvalds wrote:
>
> On Tue, 22 May 2001, Jeff Garzik wrote:
> >
> > Alan recently straightened me out with "EVMS/LVM is partitions done
> > right"
> >
> > so... why not implement partitions as simply doing block remaps to the
> > lower level device? That's what EVMS/LVM/md are doing
On Wed, 23 May 2001 [EMAIL PROTECTED] wrote:
>
> > why not implement partitions as simply doing block remaps
>
> Everybody agrees.
No they don't.
Look at the cost of lvm. Function calls, buffer head remapping, the
works. You _need_ that for a generic LVM layer, but you sure as hell don't
need
On Tue, 22 May 2001 22:52:47 +1000, Andrew Morton <[EMAIL PROTECTED]> wrote:
> Carlos Laviola wrote:
> >
> > invalid operand:
[ ... oops here ... ]
> > Segmentation fault
> >
> > This seems to be a bug in the kernel, maybe because the file is too big,
> > and VFAT partitions don't like
On Tue, 22 May 2001, Jeff Garzik wrote:
>
> Alan recently straightened me out with "EVMS/LVM is partitions done
> right"
>
> so... why not implement partitions as simply doing block remaps to the
> lower level device? That's what EVMS/LVM/md are doing already.
Because we still need the
On Tue, 22 May 2001, Jeff Garzik wrote:
>
> IMHO it would be nice to (for 2.4) create wrappers for accessing the
> block arrays, so that we can more easily dispose of the arrays when 2.5
> rolls around...
No.
We do not create wrappers "so that we can easily change the implementation
when xxx
On Tue, 22 May 2001, Alexander Viro wrote:
> >which populate the "inode->dev" union pointer, which in turn is _only_
> >a cache of the lookup. Right now we do this purely based on "dev_t",
> >and I think that is bogus. We should never pass a "dev_t" around
> >without an inode, I
Is drivers/char/ser_a2232fw.ax supposed to be included? Nothing uses it.
-
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
On Tue, 22 May 2001 11:24:54 +0200,
Daniel Phillips <[EMAIL PROTECTED]> wrote:
>On Tuesday 22 May 2001 02:59, Keith Owens wrote:
>> # Not a real dependency, this checks for hand editing of .config.
>> $(KBUILD_OBJTREE)include/linux/autoconf.h: $(KBUILD_OBJTREE).config
>> @echo Your
On Wed, 23 May 2001, Martin Knoblauch wrote:
> They may not be stupid, just mislead :-( When Intel created the "cpuid"
> Feature some way along the P3 line, they gave a stupid reason for it and
> created a big public uproar. As silly as I think that was (on both
> sides), the term "cpuid" is
Greetings,
I wanted to repost this zr36120 patch, both because so far it has gone
unnoticed, and because there was a problem with the text formatting which
is now fixed.
There is a bug in zr36120.c of not freeing memory on error paths. This one
is particularly dangerous, because kmalloc
On Wed, 23 May 2001, Tomas Telensky wrote:
> Yes. Recently I tried to transform whole cpuid code to a userspace
> utility. Not easy, not clean... but it worked.
See http://www.sourceforge.net/projects/x86info
or ftp://ftp.suse.com/pub/people/davej/x86info/
regards,
Dave.
--
| Dave Jones.
Si tiene una empresa en marcha, un proyecto o una idea registre su dominio en Internet
AHORA,
tal vez mañana sea demasiado tarde. Proteja su nombre en Internet. Si tiene ya dominio
y ha de renovarlo proximamente transfiera el dominio por solo 20$ lo tendra un año
renovado (esta operacion no
On Wed, 23 May 2001 [EMAIL PROTECTED] wrote:
> >>dev_t rdev;
>
> > Reasonable.
>
> Good. We all agree.
> (But now you see what I meant in comments about mknod.)
>
> >>kdev_t dev;
>
> > Useless. If you hope that block_device will help to solve rmmod races
>
> Yes. Why am I
> I2C Printer port detects , then
> 0x378 detects too
> but both are parport0 ?
>
> SMSC Super-IO detection, now testing Ports 2F0, 370 ...
> parport0: PC-style at 0x378 [PCSPP,TRISTATE,EPP]
Thata your parallel port
> i2c-philips-par.o: i2c Philips parallel port adapter module
>
>> dev_t rdev;
> Reasonable.
Good. We all agree.
(But now you see what I meant in comments about mknod.)
>> kdev_t dev;
> Useless. If you hope that block_device will help to solve rmmod races
Yes. Why am I mistaken?
Andries
-
To unsubscribe from this list: send the line
[EMAIL PROTECTED] wrote:
>
> > IMHO it would be nice to create wrappers for accessing the block arrays
>
> Last year Linus didnt like that at all. Maybe this year.
Well... the attached patch lines up into this effort and fixes
some abuses, removes redundant code and so on. Please have a second
> IMHO it would be nice to create wrappers for accessing the block arrays
Last year Linus didnt like that at all. Maybe this year.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
> why not implement partitions as simply doing block remaps
Everybody agrees.
Andries
-
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
On Tue, 22 May 2001, H. Peter Anvin wrote:
> Martin Knoblauch wrote:
> > >
> > > If so, then that's their problem. We're not here to solve the problem of
> > > stupid system administrators.
> > >
> >
> > They may not be stupid, just mislead :-( When Intel created the "cpuid"
> > Feature
On Tue, May 22 2001, Jeff Garzik wrote:
> IMHO it would be nice to (for 2.4) create wrappers for accessing the
> block arrays, so that we can more easily dispose of the arrays when 2.5
> rolls around...
Agreed, in fact I have a lot of stuff that could be included in the
kcompat files for 2.4 (of
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
Alexander Viro wrote:
> Do we really want a separate queue for each partition? I'd rather have
> disk_struct created when driver sees the disk and list of partitions
> (possibly represented by struct block_device) anchored in disk_struct
> and populated by grok_partitions().
Alan recently
Hi all
Find enclosed a tiny patch to the CREDITS file - I have moved house. It's
against the 2.2.19 CREDITS file, but is also relevant for the 2.4.x series.
jonathan
--- CREDITS-2.2.19 Thu May 10 09:43:35 2001
+++ CREDITS Thu May 10 09:44:15 2001
@@ -2398,8 +2398,8 @@
E: [EMAIL
Martin Knoblauch wrote:
> >
> > If so, then that's their problem. We're not here to solve the problem of
> > stupid system administrators.
> >
>
> They may not be stupid, just mislead :-( When Intel created the "cpuid"
> Feature some way along the P3 line, they gave a stupid reason for it and
On Wed, 23 May 2001 [EMAIL PROTECTED] wrote:
> I am not sure whether we agree or differ in opinion. I wouldn't mind
>
> /* pairing for dev_t to bd_op/cd_op */
> struct bc_device {
> struct list_headbd_hash;
> atomic_tbd_count;
> dev_t
"H. Peter Anvin" wrote:
>
> "Martin.Knoblauch" wrote:
> >
> > After some checking, I could have made the answer a bit less terse:
> >
> > - it would require that the kernel is compiled with cpuid [module]
> > support
> > - not everybody may want enable this, just for getting one or two
> >
On Wed, 23 May 2001, Tomas Telensky wrote:
> > Any particular reason this needs to be done in the kernel, as opposed
> It is already done in kernel, because it's displaying :)
> So, once evaluated, why not to give it to /proc/cpuinfo. I think it makes
> sense and gives it things in order.
From [EMAIL PROTECTED] Wed May 23 00:39:23 2001
On Tue, 22 May 2001 [EMAIL PROTECTED] wrote:
>
> The operations are different, but all bdev/cdev code is identical.
>
> So the choice is between two uglies:
> (i) have some not entirely trivial amount of code twice in
I tried to give you some pointers in a personal email. So it's not true
you didn't receive any response. Also reminded you of the best place to
look for info, namely, that driver's mailing list. You don't seem to
have made any additional attempts at resolving it yourself since you
reposted your
Hi folks,(cc me, as i'm not on the list)
[1.] One line summary of the problem:
Kernel 2.4.4 oopses during boot
[2.] Full description of the problem/report:
Kernel 2.4.4 oopses during boot on RH 7.1 system, seems when it's
running kudzu or something (maybe I saw it wrong)
On Wed, 23 May 2001, Xuan Baldauf wrote:
> Urban Widmark wrote:
>
> > The only other way I have found so far to get it to return the right file
> > size is to do a "seek-to-end". That still means an extra SMB but it avoids
> > the very painful "sync to disk".
> >
> > Fortunately the seek is
Urban Widmark wrote:
> On Mon, 21 May 2001, Xuan Baldauf wrote:
>
> > That is annoying, because it heavily slows down bulk transfers of small
> > writes, like automatically unzipping a new mozilla build from the linux box to
> > the windows box. Every write of say 100 bytes is implemented as
>
And if we are at the topic... Those are the places where blk_size[]
get's
abused, since it's in fact a property of a FS in fact and not the
property of
a particular device... blksect_size is the array describing the physical
access limits of a device and blk_size get's usually checked against it.
On 21 May 2001, H. Peter Anvin wrote:
> 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
On Tue, 22 May 2001 [EMAIL PROTECTED] wrote:
>
> The operations are different, but all bdev/cdev code is identical.
>
> So the choice is between two uglies:
> (i) have some not entirely trivial amount of code twice in the kernel
> (ii) have a union at the point where the struct operations
> is
[EMAIL PROTECTED] wrote:
>
> Martin Dalecki writes:
>
> > Erm... I wasn't talking about the DESIRED state of affairs!
> > I was talking about the CURRENT state of affairs. OK?
>
> Oh, but in 1995 it was quite possible to compile the kernel
> with kdev_t a pointer type, and I have done it
> I have an analog joystick plugged into the gameport of a Soundblaster
> AWE64. In 2.4.4-ac12 this was recognized and worked just fine. Under
> ac13 the recognition is incomplete - it seems to identify that there
> is a NS558 gameport device present, but not that there is a joystick
> plugged
On Mon, 21 May 2001, Xuan Baldauf wrote:
> That is annoying, because it heavily slows down bulk transfers of small
> writes, like automatically unzipping a new mozilla build from the linux box to
> the windows box. Every write of say 100 bytes is implemented as
>
> send write req
> recv write
Ashok wrote:
> Is there a method to schedule user mode code from
> kernel agent? ...
> windows 2000 offers 2 such facilities. (APC or async
> procedure calls) where a thread can block and when
> ready will be woken via the kernel agent and can run a
> user supplied function.
>
> or a method to
I'm trying to call ioremap fairly early on in kernel init (and it
doesn't work ;-) )
What setup functions have to run before ioremap() will work?
I can debug exactly what it's doing now if I have to, but I
don't suspect it'll tell me much ... I'm calling from aroung
console_init in
Martin Dalecki writes:
> Erm... I wasn't talking about the DESIRED state of affairs!
> I was talking about the CURRENT state of affairs. OK?
Oh, but in 1995 it was quite possible to compile the kernel
with kdev_t a pointer type, and I have done it several times since.
The kernel keeps growing,
On Tue, 22 May 2001 [EMAIL PROTECTED] wrote:
> This sounds like a bug I have heard before: some switches don't work with
> the xircom card (well, our drivers for it) when doing full duplex.
> Could you try the latest driver from
>
> http://people.redhat.com/arjanv
>
> which forces the card to
Alan Cox <[EMAIL PROTECTED]> écrit :
[...]
> o Add missing locking to stradis driver (me)
- unbalanced returns after down();
- 1770: if the initial version isn't racy with saa7146_irq (line 534), this
one is equivalent and shorter.
init_saa7146:2185
if ((saa->dmadebi =
[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 knowlendge of
> > the minor number.
>
> My
Richard Gooch <[EMAIL PROTECTED]> writes:
> Sure, Dave is being bloody-minded, but that's the only way we'll see
> people get off their fat, lazy asses and fix their broken systems.
> In fact, hopefully he's still in a dark mood, and he may take up the
> suggestion to bounce mails of the
I have an analog joystick plugged into the gameport of a Soundblaster
AWE64. In 2.4.4-ac12 this was recognized and worked just fine. Under
ac13 the recognition is incomplete - it seems to identify that there
is a NS558 gameport device present, but not that there is a joystick
plugged into it
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 knowlendge of
> the minor number.
My kdev_t is a pointer to a structure with device data
In article <[EMAIL PROTECTED]> you wrote:
> On Tue, 22 May 2001 20:10:41 +0100 (BST), Alan Cox <[EMAIL PROTECTED]> wrote:
>> Before you give up on the xircom thing, try the -ac kernel and set the box
>> up to use xircom_cb not xircom_tulip_cb
>>
>> That might help a lot
> It doesn't, it still
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
Intermediate diffs are available from
http://www.bzimage.org
Rather than starting to propogate these fixes to other drivers I'd be
greatful if they would audit the changes (especially the
At 10:24 PM +0100 2001-05-22, Alan Cox wrote:
> > On the main board, and not just the old ones. These days it's
>> typically in the chipset's south bridge. "Third-party DMA" is
>> sometimes called "fly-by DMA". The ISA card is a slave, as is memory,
>> and the DMA chip reads from one ands
On Tue, 22 May 2001 20:10:41 +0100 (BST), Alan Cox <[EMAIL PROTECTED]> wrote:
> Before you give up on the xircom thing, try the -ac kernel and set the box
> up to use xircom_cb not xircom_tulip_cb
>
> That might help a lot
It doesn't, it still performs poorly with any of the three available
At 2:02 PM -0700 2001-05-22, Richard Henderson wrote:
>On Tue, May 22, 2001 at 01:48:23PM -0700, Jonathan Lundell wrote:
>> 64KB for 8-bit DMA; 128KB for 16-bit DMA. [...] This doesn't
>> apply to bus-master DMA, just the legacy (8237) stuff.
>
>Would this 8237 be something on the ISA card, or
[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
Hello All,
I will be using Linux as the OS for an embedded system.
I was looking into 2.4.4 kernel code and saw the dcache implementation
in VFS which is pretty neat and fast by itself.
My question is, will I gain any considerable efficiency in file system
access
if I can move this
> On Tue, May 22, 2001 at 05:00:16PM +0200, Andrea Arcangeli wrote:
> > I'm also wondering if ISA needs the sg to start on a 64k boundary,
> Traditionally, ISA could not do DMA across a 64k boundary.
The ISA dmac on the x86 needs a 64K boundary (128K for 16bit) because it
did not carry the 16
> Is there a method to schedule user mode code from kernel agent?
You can wake user processes,send them signals etc but ingeneral its not
a good idea
> registers with the kernel mode agent with a function/parm to run, then when
> the callback is appropriate the kerenl agent triggers this
> ISA cards can do sg?
AHA1542 scsi for one. It wasnt that uncommon.
-
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
Hi!
> > > [..] Even sparc64's fancy
> > > iommu-based pci_map_single() always succeeds.
> >
> > Whatever sparc64 does to hide the driver bugs you can break it if you
> > pci_map 4G+1 bytes of phyical memory.
>
> Which is an utterly stupid thing to do.
>
> Please construct a plausable
Hi!
> > I've seen this question several times in this thread. I haven't seen the
> > obvious answer, though.
> >
> > Have a new system call:
> >
> > ctlfd = open_device_control_fd(fd);
> >
> > If fd is something that doesn't have a control interface (say, it already
> > is a control
On Tue, May 22, 2001 at 01:48:23PM -0700, Jonathan Lundell wrote:
> 64KB for 8-bit DMA; 128KB for 16-bit DMA. [...] This doesn't
> apply to bus-master DMA, just the legacy (8237) stuff.
Would this 8237 be something on the ISA card, or something on
the old pc mainboards? I'm wondering if we can
> 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 is identical.
So the choice is between
Andreas,
I think that the issue is something different. Suppose the snapshot has
been created. I know that this can be done safely with the API's you
allude to. Life goes on and the journal FS keeps changing the file system
and if the system doesn't crash, everything is fine: blocks get
On Tue, May 22, 2001 at 04:40:17PM -0400, Jeff Garzik wrote:
> ISA cards can do sg?
No, but the host iommu can. The isa card sees whatever
view of memory presented to it by the iommu.
r~
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
At 1:28 PM -0700 2001-05-22, Richard Henderson wrote:
>On Tue, May 22, 2001 at 05:00:16PM +0200, Andrea Arcangeli wrote:
>> I'm also wondering if ISA needs the sg to start on a 64k boundary,
>
>Traditionally, ISA could not do DMA across a 64k boundary.
>
>The only ISA card I have (a soundblaster
Hi,
I searched the lkml for previous reports of this error, and I've found a few
questions asked, but no real answer given. I'm not looking for a quick
answer, but this just seems to be an issue that hasn't been touched on much.
Any thoughts (and solutions) would be greatly appreciated.
I'm
Jonathan Morton <[EMAIL PROTECTED]>:
> I'm going to assume for now that CML2 saves two files - one storing a
> relatively small number of symbols (which is strictly limited to those
> explicitly set by the user), and one containing the full set for
> consumption by the Makefiles.
No, that's not
On Tue, May 22, 2001 at 05:00:16PM +0200, Andrea Arcangeli wrote:
> I'm also wondering if ISA needs the sg to start on a 64k boundary,
Traditionally, ISA could not do DMA across a 64k boundary.
The only ISA card I have (a soundblaster compatible) appears
to work without caring for this, but I
Hi,
I have discovered that my previous problem with immediate lockups of all
kernels versioon >2.4.3 is USB and/or sound-related. My computer currently
has onte internal soundcard (awe64) that is not used, and an external USB
D/A. Playing a sound with the internal soundcard (cat whatever >
On Tuesday 22 May 2001 19:49, Oliver Xymoron wrote:
> On Tue, 22 May 2001, Daniel Phillips wrote:
> > > I don't think it's likely to be even workable. Just consider the
> > > directory entry for a moment - is it going to be marked d or
> > > [cb]?
> >
> > It's going to be marked 'd', it's a
Hello Gurus...
Is there a method to schedule user mode code from kernel agent?
basically think that when some work is to be scheduled in user mode, the app
registers with the kernel mode agent with a function/parm to run, then when
the callback is appropriate the kerenl agent triggers this
On Tue, May 22, 2001 at 10:04:39PM +0200, Andrea Arcangeli wrote:
> diff -urN 2.4.5pre4/arch/alpha/kernel/pci_iommu.c
>2.4.5pre5/arch/alpha/kernel/pci_iommu.c
> --- 2.4.5pre4/arch/alpha/kernel/pci_iommu.c Sun Apr 1 01:17:07 2001
> +++ 2.4.5pre5/arch/alpha/kernel/pci_iommu.c Tue May 22
On Tue, 22 May 2001 [EMAIL PROTECTED] wrote:
> One remark, repeating what I wrote on some web page:
> -
> A struct block_device provides the connection between a device number
> and a struct block_device_operations.
> ...
> Clearly, we also want to associate a struct
Alexander Viro writes:
> patch below adds the missing half of kdev_t -
> for block devices we already have a unique pointer
> and that adds a similar animal for character devices.
Very good.
(Of course I did precisely the same, but am a bit slower in
submitting things during a stable series or
On Tue, 22 May 2001, Guest section DW wrote:
> On Tue, May 22, 2001 at 11:08:16AM -0500, Oliver Xymoron wrote:
>
> > > >+ struct list_headhash;
>
> > > Why not name consistently with the struct block_device?
> > > struct list_headcd_hash;
>
> > Because foo_ is a
On Tue, 22 May 2001, Alan Cox wrote:
> > I currently have three Xircom RealPort Carbus modem/fast ethernet cards.
> > The current driver blows major chunks (it has very poor performance, and
> > stops working under load). I'm told the driver issues are because of
> > hardware issues. The really
Linus writes:
0 is EOF _for_reads_. For writes it is not very well defined
Hmm.
So -EFBIG is certainly the preferable return value,
Yes. The Austin 6th draft writes
EFBIG:
An attempt was made to write a file that exceeds the implementation-defined
maximum file size or the
On Tue, 22 May 2001, Guest section DW wrote:
> One often has to go through all occurrences of a variable or
> field of a struct. That is much easier with cd_hash and cd_dev
> than with hash and dev.
>
> No, it is a good habit, these prefixes, even though it is no longer
> necessary because of
On Tue, May 22, 2001 at 11:08:16AM -0500, Oliver Xymoron wrote:
> > >+ struct list_headhash;
> > Why not name consistently with the struct block_device?
> > struct list_headcd_hash;
> Because foo_ is a throwback to the days when C compilers had a single
>
On Tue, 22 May 2001, Linus Torvalds wrote:
>
> On Tue, 22 May 2001, Andreas Dilger wrote: Actually, the LVM snapshot
> interface has (optional) hooks into the filesystem to ensure that it
> is consistent at the time the snapshot is created.
But I think that LVM is implemented "the wrong way
> I currently have three Xircom RealPort Carbus modem/fast ethernet cards.
> The current driver blows major chunks (it has very poor performance, and
> stops working under load). I'm told the driver issues are because of
> hardware issues. The really nice feature of this card is the form factor
I currently have three Xircom RealPort Carbus modem/fast ethernet cards.
The current driver blows major chunks (it has very poor performance, and
stops working under load). I'm told the driver issues are because of
hardware issues. The really nice feature of this card is the form factor
though.
On Tue, 22 May 2001, Andreas Dilger wrote:
>
> Actually, the LVM snapshot interface has (optional) hooks into the filesystem
> to ensure that it is consistent at the time the snapshot is created.
Note that this is still fundamentally a broken interface: the filesystem
may not _have_ a block
On Tue, 22 May 2001, Alan Cox wrote:
> Are there specific reasons you cannot just use the existing ioctls to load
> fonts ? The console driver already supports Klingon for example.
>
> What are the issues - writing right - left ?
No, but in some scripts [devanagari anyway] you only ever write
>> What is the communication between user space and kernel
>> that transports device identities?
> It doesn't change, the same symbolic names still work.
But today, unless you think of devfs or so, device identities
are not transported by symbolic names. They are given by
device numbers.
[Yes,
On Tue, 22 May 2001, null wrote:
> Here is some additional info about the 2.4 performance defect.
>
> Only one person offered a suggestion about the use of HIGHMEM. I tried
> with and without HIGHMEM enabled with the same results. However, it does
> appear to take a bit longer to reach
Followup to: <[EMAIL PROTECTED]>
By author:Alan Cox <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> > We are interested in making some changes to the linux kernel so that it
> > supports some indian type fonts on the console... so what are the special
> > things that we sould take
Linus Torvalds wrote:
>
[deletia]
>
> So returning 0 for write() is usually a bad idea - exactly because it
> does not have very well-defined semantics. So -EFBIG is certainly the
> preferable return value, and seems to be what SuS wants, too.
And what LFS wants too:
2.2.1.27 write() and
1 - 100 of 463 matches
Mail list logo