Hi,
On Sat, 29 Jan 2005, Dmitry Torokhov wrote:
I can assure you that serio_raw driver _does not_ use input system - it is
implementation of pre 2.6 /dev/psaux interface giving you access to raw AUX
data. It was written so we can still use PS/2 devices for which we don't have
proper
Hi,
On Sat, 29 Jan 2005, Dmitry Torokhov wrote:
That's fine, but why is it in the input menu? How do you suggest to make
it selectable without selecting input and without messing the menu
structure?
Well, probably split input into sections, one of the options would be
something like
Hi,
On Sat, 29 Jan 2005, Dmitry Torokhov wrote:
Well, with the current Kconfig I can de-select INPUT and still select
serio and serio_raw and access my AUX port via /dev/psaux. I don't know
if anyone would really do it, but why not?
Btw, what was the point of your patch?
See the subject.
Hi,
On Thu, 27 Jan 2005, Andries Brouwer wrote:
> In short - raw mode in 2.6 is badly broken.
I think not just that. The whole keyboard input layer needs some serious
review. Just the complete lack of any locking is frightening, I'd really
like to know how the input layer could become the
Hi,
On Thu, 27 Jan 2005, Andries Brouwer wrote:
In short - raw mode in 2.6 is badly broken.
I think not just that. The whole keyboard input layer needs some serious
review. Just the complete lack of any locking is frightening, I'd really
like to know how the input layer could become the
Hi,
On Tue, 25 Jan 2005, Pavel Fedin wrote:
> > how about just leave the characters unchanged? (remap them to the same
> > codes in Unicode).
>
> But what to do when i convert then from unicode to 8-bit iocharset?
> This can lead to that several characters in Mac charset will be
> converted
release_console_sem();
vcs_remove_devfs(tty);
From: Roman Zippel <[EMAIL PROTECTED]>
The vt_struct and vc_data are always allocated together, so there is no need
for a separate vt_struct structure.
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton
();
vcs_remove_devfs(tty);
From: Roman Zippel [EMAIL PROTECTED]
The vt_struct and vc_data are always allocated together, so there is no need
for a separate vt_struct structure.
Signed-off-by: Roman Zippel [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/char/selection.c
Hi,
On Tue, 25 Jan 2005, Pavel Fedin wrote:
how about just leave the characters unchanged? (remap them to the same
codes in Unicode).
But what to do when i convert then from unicode to 8-bit iocharset?
This can lead to that several characters in Mac charset will be
converted to the
Hi,
On Mon, 24 Jan 2005, Andrew Morton wrote:
> - On my test box there is no flashing cursor on the vga console. Known bug,
> please don't report it.
>
> Binary searching shows that the bug was introduced by
> cleanup-vc-array-access.patch but that patch is, unfortunately, huge.
I
Hi,
On Mon, 24 Jan 2005, Andrew Morton wrote:
- On my test box there is no flashing cursor on the vga console. Known bug,
please don't report it.
Binary searching shows that the bug was introduced by
cleanup-vc-array-access.patch but that patch is, unfortunately, huge.
I introduced
Hi,
On Sun, 23 Jan 2005, Karim Yaghmour wrote:
> But how does relayfs organize the namespace then? What if I have
> multiple channels per CPU, each for a different type of data, will
> all channels for the same CPU be under the same directory or will
> each type of data have its own directory
Hi,
On Sun, 23 Jan 2005, Karim Yaghmour wrote:
But how does relayfs organize the namespace then? What if I have
multiple channels per CPU, each for a different type of data, will
all channels for the same CPU be under the same directory or will
each type of data have its own directory with
Hi,
On Fri, 21 Jan 2005, Andrew Morton wrote:
> Paul Mackerras <[EMAIL PROTECTED]> wrote:
> >
> > A cluster of 2^n contiguous pages
> > isn't one page by any normal definition.
>
> It is, actually, from the POV of the page allocator. It's a "higher order
> page" and is controlled by a struct
Hi,
On Fri, 21 Jan 2005, Karim Yaghmour wrote:
> I should have avoided earlier confusing the use of a certain type of
> relayfs channel for a given purpose (i.e. LTT should not necessarily
> depend on the managed mode.) I believe that there is a need for
> more than one mode in relayfs
Hi,
On Fri, 21 Jan 2005, James Simmons wrote:
> Please don't remove strutc vt_struct. What should be done is that struct
> vt_struct is used to hold the data that is shared amoung all the VCs. For
> example struct consw. See we end up with something like this.
>
> struct vt_struct {
>
Hi,
On Thu, 20 Jan 2005, Matt Mackall wrote:
> On Thu, Jan 20, 2005 at 08:07:11PM -0800, Andrew Morton wrote:
> > Andrew Morton <[EMAIL PROTECTED]> wrote:
> > >
> > > Next suspects would be:
> > >
> > > +cleanup-vc-array-access.patch
> > > +remove-console_macrosh.patch
> > >
Hi,
On Thu, 20 Jan 2005, Matt Mackall wrote:
On Thu, Jan 20, 2005 at 08:07:11PM -0800, Andrew Morton wrote:
Andrew Morton [EMAIL PROTECTED] wrote:
Next suspects would be:
+cleanup-vc-array-access.patch
+remove-console_macrosh.patch
+merge-vt_struct-into-vc_data.patch
Hi,
On Fri, 21 Jan 2005, James Simmons wrote:
Please don't remove strutc vt_struct. What should be done is that struct
vt_struct is used to hold the data that is shared amoung all the VCs. For
example struct consw. See we end up with something like this.
struct vt_struct {
const
Hi,
On Fri, 21 Jan 2005, Karim Yaghmour wrote:
I should have avoided earlier confusing the use of a certain type of
relayfs channel for a given purpose (i.e. LTT should not necessarily
depend on the managed mode.) I believe that there is a need for
more than one mode in relayfs independently
Hi,
On Fri, 21 Jan 2005, Andrew Morton wrote:
Paul Mackerras [EMAIL PROTECTED] wrote:
A cluster of 2^n contiguous pages
isn't one page by any normal definition.
It is, actually, from the POV of the page allocator. It's a higher order
page and is controlled by a struct page*, just
Hi,
On Wed, 19 Jan 2005, Andreas Gruenbacher wrote:
> Okay, more verbose then. On your machine which is running kernel version
> x you build kernel version y. You grab the version y kernel source tree,
> let's say a vendor tree, which has meaningful default configurations in
>
Hi,
On Wed, 19 Jan 2005, Andreas Gruenbacher wrote:
> > > A user ran into the following problem: They grab a SuSE kernel-source
> > > package that is more recent than their running kernel. The tree under
> > > /usr/src/linux is unconfigured by default; there is no .config. User
> > > does a
Hi,
On Wed, 19 Jan 2005, Andreas Gruenbacher wrote:
A user ran into the following problem: They grab a SuSE kernel-source
package that is more recent than their running kernel. The tree under
/usr/src/linux is unconfigured by default; there is no .config. User
does a ``make
Hi,
On Wed, 19 Jan 2005, Andreas Gruenbacher wrote:
Okay, more verbose then. On your machine which is running kernel version
x you build kernel version y. You grab the version y kernel source tree,
let's say a vendor tree, which has meaningful default configurations in
arch/$ARCH/defconfig.
Hi,
On Tue, 18 Jan 2005, Andreas Gruenbacher wrote:
> A user ran into the following problem: They grab a SuSE kernel-source
> package that is more recent than their running kernel. The tree under
> /usr/src/linux is unconfigured by default; there is no .config. User
> does a ``make menuconfig'',
Hi,
On Mon, 17 Jan 2005, Karim Yaghmour wrote:
> With that said, I hope we've agreed that we'll have a callback for
> letting relayfs clients know that they need to write the begining of
> the buffer event. There won't be any associated reserve. Conversly,
> I hope it is not too much to ask to
Hi,
On Mon, 17 Jan 2005, Karim Yaghmour wrote:
With that said, I hope we've agreed that we'll have a callback for
letting relayfs clients know that they need to write the begining of
the buffer event. There won't be any associated reserve. Conversly,
I hope it is not too much to ask to have
Hi,
On Tue, 18 Jan 2005, Andreas Gruenbacher wrote:
A user ran into the following problem: They grab a SuSE kernel-source
package that is more recent than their running kernel. The tree under
/usr/src/linux is unconfigured by default; there is no .config. User
does a ``make menuconfig'',
Hi,
On Mon, 17 Jan 2005, Karim Yaghmour wrote:
> a) create indexes, b) reorder events, and likely c) have to rewrite
An additional comment about the order of events. What you're doing in
lockless_reserve is bogus anyway. There is no single correct time to
write into the event. By artificially
Hi,
On Mon, 17 Jan 2005, Karim Yaghmour wrote:
> > Periodically can also mean a buffer start call back from relayfs
> > (although that would mean the first entry is not guaranteed) or a
> > (per cpu) eventcnt from the subsystem. The amount of needed search would
> > be limited. The main point
Hi,
On Sun, 16 Jan 2005, Karim Yaghmour wrote:
> > You can make it even simpler by dropping this completely. Every buffer is
> > simply a list of events and you can let ltt write periodically a timer
> > event. In userspace you can randomly seek at buffer boundaries and search
> > for the
Hi,
On Sun, 16 Jan 2005, Karim Yaghmour wrote:
You can make it even simpler by dropping this completely. Every buffer is
simply a list of events and you can let ltt write periodically a timer
event. In userspace you can randomly seek at buffer boundaries and search
for the timer
Hi,
On Mon, 17 Jan 2005, Karim Yaghmour wrote:
Periodically can also mean a buffer start call back from relayfs
(although that would mean the first entry is not guaranteed) or a
(per cpu) eventcnt from the subsystem. The amount of needed search would
be limited. The main point is from
Hi,
On Mon, 17 Jan 2005, Karim Yaghmour wrote:
a) create indexes, b) reorder events, and likely c) have to rewrite
An additional comment about the order of events. What you're doing in
lockless_reserve is bogus anyway. There is no single correct time to
write into the event. By artificially
Hi,
On Sun, 16 Jan 2005, Karim Yaghmour wrote:
> The per-cpu buffering issue is really specific to the client. It just
> so happens that LTT creates one channel for each CPU. Not everyone
> who needs to ship lots of data to user-space needs/wants one channel
> per cpu. You could, for example,
Hi,
On Sun, 16 Jan 2005, Karim Yaghmour wrote:
The per-cpu buffering issue is really specific to the client. It just
so happens that LTT creates one channel for each CPU. Not everyone
who needs to ship lots of data to user-space needs/wants one channel
per cpu. You could, for example, use a
Hi,
On Sat, 15 Jan 2005, Karim Yaghmour wrote:
> In addition, and this is a very important issue, quite a few
> kernel developers mistook LTT for a kernel debugging tool, which
> it was never meant to be. When, in fact, if you ask those who have
> looked at using it for that purpose (try Marcelo
Hi,
On Fri, 14 Jan 2005, Karim Yaghmour wrote:
> > Why should a subsystem care about the details of the buffer management?
>
> Because it wants to enforce a data format on buffer boundaries.
It's interesting to read more about ltt's requirements, but I still think
it's possible to leave this
Hi,
On Fri, 14 Jan 2005, Karim Yaghmour wrote:
Why should a subsystem care about the details of the buffer management?
Because it wants to enforce a data format on buffer boundaries.
It's interesting to read more about ltt's requirements, but I still think
it's possible to leave this work
Hi,
On Sat, 15 Jan 2005, Karim Yaghmour wrote:
In addition, and this is a very important issue, quite a few
kernel developers mistook LTT for a kernel debugging tool, which
it was never meant to be. When, in fact, if you ask those who have
looked at using it for that purpose (try Marcelo or
Hi,
In do_swap_page() we don't flush read ahead pages to memory, so the cpu
might read the wrong data into the icache. I can reproduce this on my ppc
machine and the patch below fixes this problem.
If the patch is ok, you might also want to remove the wait_on_page() since
the following
Hi,
In do_swap_page() we don't flush read ahead pages to memory, so the cpu
might read the wrong data into the icache. I can reproduce this on my ppc
machine and the patch below fixes this problem.
If the patch is ok, you might also want to remove the wait_on_page() since
the following
Hi,
Martin Wilck wrote:
> Hum - is there no simple way to determine whether a pointer is
> a valid pointer to something returned by __get_free_pages ()? You are
> right, S390 in particular seems to allow arbitrary addresses starting from
> 0.
M68k does so too, although the first page is never
Hi,
Martin Wilck wrote:
Hum - is there no simple way to determine whether a pointer is
a valid pointer to something returned by __get_free_pages ()? You are
right, S390 in particular seems to allow arbitrary addresses starting from
0.
M68k does so too, although the first page is never used
Hi,
On Sun, 17 Jun 2001, Alexander Viro wrote:
> > typeof? It's rather popular in the kernel already. Besides, who is going to
>
> Really? 5 instances in PPC arch-specific code, 1 (absolutely gratitious)
> in drivers/mtd, 2 - in m68k (also useless), 4 - in drivers/video, 2 -
> in AFFS and 1 -
Hi,
On Sun, 17 Jun 2001, Alexander Viro wrote:
typeof? It's rather popular in the kernel already. Besides, who is going to
Really? 5 instances in PPC arch-specific code, 1 (absolutely gratitious)
in drivers/mtd, 2 - in m68k (also useless), 4 - in drivers/video, 2 -
in AFFS and 1 - in
Hi,
Jes Sorensen wrote:
> In principle you just need 2.7.2.3 for m68k, but someone decided to
> raise the bar for all architectures by putting a check in a common
> header file.
IIRC 2.7.2.3 has problems with labeled initializers for structures,
which makes 2.7.2.3 unusable for all archs under
Hi,
Jes Sorensen wrote:
In principle you just need 2.7.2.3 for m68k, but someone decided to
raise the bar for all architectures by putting a check in a common
header file.
IIRC 2.7.2.3 has problems with labeled initializers for structures,
which makes 2.7.2.3 unusable for all archs under
Hi,
Alexander Viro wrote:
> unlink("/B/b") locks /B, removes "b" and unlocks /B. Then it calls
> affs_remove_link(), which blocks.
>
> unlink("/A/a") locks /A, removes "a" and unlocks /A. Then it calls
> affs_remove_link(). Which locks /B, renames removed entry into "b",
> removes old "b" and
Hi,
Mark Hounschell wrote:
> Sorry I didn't get back to you yesterday afternoon. I was out of town.
> Attached is the output from dmesg and the relavent info from
> /var/log/messages.
Could you try the attached patch? I forgot to initialize a variable
correctly.
(I also put a new version at
Hi,
Mark Hounschell wrote:
Sorry I didn't get back to you yesterday afternoon. I was out of town.
Attached is the output from dmesg and the relavent info from
/var/log/messages.
Could you try the attached patch? I forgot to initialize a variable
correctly.
(I also put a new version at
Hi,
Mark Hounschell wrote:
> Thanks, I can now mount affs filesystems. However when I try to write
> to it via "cp somefile /amiga/somefile" I get a segmentation fault. If
> I then do a "df -h" it hangs the system very much like the mount command
> did before I installed your tar-ball. Was
Hi,
Mark Hounschell wrote:
Thanks, I can now mount affs filesystems. However when I try to write
to it via "cp somefile /amiga/somefile" I get a segmentation fault. If
I then do a "df -h" it hangs the system very much like the mount command
did before I installed your tar-ball. Was write
Hi,
Mark Hounschell wrote:
> I'm not a list member so IF you respond to this mail please CC me.
> I've been looking at the archives and see some problems with the 2.3.x
> kernel versions and affs support.
I've put a new version at
http://www.xs4all.nl/~zippel/affs.010414.tar.gz
bye, Roman
-
Hi,
Mark Hounschell wrote:
I'm not a list member so IF you respond to this mail please CC me.
I've been looking at the archives and see some problems with the 2.3.x
kernel versions and affs support.
I've put a new version at
http://www.xs4all.nl/~zippel/affs.010414.tar.gz
bye, Roman
-
To
Hi,
On Thu, 8 Mar 2001, God wrote:
> Look at some of the confirmation requests in windows, some ask you twice
> if you whish to perform an action. Even Red Hat (that I know of, others
> may as well), has an alias for "rm" that by
> default turns on confirmation. Why? Because not ALL users
Hi,
On Thu, 8 Mar 2001, God wrote:
Look at some of the confirmation requests in windows, some ask you twice
if you whish to perform an action. Even Red Hat (that I know of, others
may as well), has an alias for "rm" that by
default turns on confirmation. Why? Because not ALL users will
Hi,
On Thu, 1 Mar 2001, Alexander Viro wrote:
> IOW, if it's worth doing at all it probably should be
> on expanding path in vmtruncate() - limit checks are already
> done, but old i_size is still not lost...
The fs where it's important have mmu_private, that's what I use to decide
Hi,
On Thu, 1 Mar 2001, Alexander Viro wrote:
> +static int generic_vm_expand(struct address_space *mapping, loff_t size)
> +{
> + struct page *page;
> + unsigned long index, offset;
> + int err;
> +
> + if (!mapping->a_ops->prepare_write || !mapping->a_ops->commit_write)
> +
Hi,
On Thu, 1 Mar 2001, Alexander Viro wrote:
+static int generic_vm_expand(struct address_space *mapping, loff_t size)
+{
+ struct page *page;
+ unsigned long index, offset;
+ int err;
+
+ if (!mapping-a_ops-prepare_write || !mapping-a_ops-commit_write)
+
Hi,
On Thu, 1 Mar 2001, Alexander Viro wrote:
IOW, if it's worth doing at all it probably should be
on expanding path in vmtruncate() - limit checks are already
done, but old i_size is still not lost...
The fs where it's important have mmu_private, that's what I use to decide
whether
Hi,
On Tue, 20 Feb 2001, Trond Myklebust wrote:
> If I read the code correctly, we set the dentry d_flag
> DCACHE_NFSD_DISCONNECTED on such dummy dentries. We only force a
> lookup of the full path if the inode represents a directory or the
> NFSEXP_NOSUBTREECHECK export flag is not set.
IMO
Hi,
On 20 Feb 2001, Trond Myklebust wrote:
> IIRC several NFS implementations (not Linux though) rely on being able
> to walk back up the directory tree in order to discover the path at
> any given moment.
If I read the source correctly, namespace operation are done with dir file
handle + file
Hi,
On 20 Feb 2001, Trond Myklebust wrote:
IIRC several NFS implementations (not Linux though) rely on being able
to walk back up the directory tree in order to discover the path at
any given moment.
If I read the source correctly, namespace operation are done with dir file
handle + file
Hi,
On Tue, 20 Feb 2001, Trond Myklebust wrote:
If I read the code correctly, we set the dentry d_flag
DCACHE_NFSD_DISCONNECTED on such dummy dentries. We only force a
lookup of the full path if the inode represents a directory or the
NFSEXP_NOSUBTREECHECK export flag is not set.
IMO you
Hi,
On Tue, 20 Feb 2001, Neil Brown wrote:
> 2/ lookup("..").
A small question:
Why exactly is this needed?
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Hi,
On Tue, 20 Feb 2001, Neil Brown wrote:
2/ lookup("..").
A small question:
Why exactly is this needed?
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Hi,
On Mon, 5 Feb 2001, Linus Torvalds wrote:
> > Does it has to be vectors? What about lists?
>
> I'd prefer to avoid lists unless there is some overriding concern, like a
> real implementation issue. But I don't care much one way or the other -
> what I care about is that the setup and usage
Hi,
On Mon, 5 Feb 2001, Linus Torvalds wrote:
> This all proves that the lowest level of layering should be pretty much
> noting but the vectors. No callbacks, no crap like that. That's already a
> level of abstraction away, and should not get tacked on. Your lowest level
> of abstraction
Hi,
On Mon, 5 Feb 2001, Linus Torvalds wrote:
This all proves that the lowest level of layering should be pretty much
noting but the vectors. No callbacks, no crap like that. That's already a
level of abstraction away, and should not get tacked on. Your lowest level
of abstraction should be
Hi,
On Mon, 29 Jan 2001, Andi Kleen wrote:
> You can miss wakeups. The standard pattern is:
>
> get locks
>
> add_wait_queue(, );
> for (;;) {
> if (condition you're waiting for is true)
> break;
> unlock any non sleeping
Hi,
On Mon, 29 Jan 2001, Andi Kleen wrote:
You can miss wakeups. The standard pattern is:
get locks
add_wait_queue(waitqueue, wait);
for (;;) {
if (condition you're waiting for is true)
break;
unlock any non
Hi,
On Sun, 28 Jan 2001, Manfred Spraul wrote:
> And one more point for the Janitor's list:
> Get rid of superflous irqsave()/irqrestore()'s - in 90% of the cases
> either spin_lock_irq() or spin_lock() is sufficient. That's both faster
> and better readable.
>
> spin_lock_irq(): you know that
Hi,
On Sun, 28 Jan 2001, Manfred Spraul wrote:
And one more point for the Janitor's list:
Get rid of superflous irqsave()/irqrestore()'s - in 90% of the cases
either spin_lock_irq() or spin_lock() is sufficient. That's both faster
and better readable.
spin_lock_irq(): you know that the
Hi,
Timur Tabi wrote:
> I mark the page as reserved when I ioremap() it. However, if I leave it marked
> reserved, then iounmap() will not unmap it. If I mark it "unreserved" (i.e.
> reset the reserved bit), then iounmap will unmap it, but it will decrement the
> page counter to -1 and the
Hi,
Timur Tabi wrote:
I mark the page as reserved when I ioremap() it. However, if I leave it marked
reserved, then iounmap() will not unmap it. If I mark it "unreserved" (i.e.
reset the reserved bit), then iounmap will unmap it, but it will decrement the
page counter to -1 and the whole
Hi,
On Tue, 23 Jan 2001, Mark Mokryn wrote:
> ioremap_nocache does the following:
> return __ioremap(offset, size, _PAGE_PCD);
>
> However, in drivers/char/mem.c (2.4.0), we see the following:
>
> /* On PPro and successors, PCD alone doesn't always mean
> uncached
Hi,
On Tue, 23 Jan 2001, Mark Mokryn wrote:
ioremap_nocache does the following:
return __ioremap(offset, size, _PAGE_PCD);
However, in drivers/char/mem.c (2.4.0), we see the following:
/* On PPro and successors, PCD alone doesn't always mean
uncached because of
Hi,
On Sat, 20 Jan 2001, Linus Torvalds wrote:
> But think like a good hardware designer.
>
> In 99% of all cases, where do you want the results of a read to end up?
> Where do you want the contents of a write to come from?
>
> Right. Memory.
>
> Now, optimize for the common case. Make the
Hi,
On Sat, 20 Jan 2001, Linus Torvalds wrote:
> Now, there are things to look out for: when you do these kinds of dummy
> "struct page" tricks, some macros etc WILL NOT WORK. In particular, we do
> not currently have a good "page_to_bus/phys()" function. That means that
> anybody trying to do
Hi,
On Sat, 20 Jan 2001, Linus Torvalds wrote:
> But point-to-point also means that you don't get any real advantage from
> doing things like device-to-device DMA. Because the links are
> asynchronous, you need buffers in between them anyway, and there is no
> bandwidth advantage of not going
Hi,
On Sat, 20 Jan 2001, Linus Torvalds wrote:
> There's no no-no here: you can even create the "struct page"s on demand,
> and create a dummy local zone that contains them that they all point back
> to. It should be trivial - nobody else cares about those pages or that
> zone anyway.
AFAIK as
Hi,
On Sat, 20 Jan 2001, Linus Torvalds wrote:
There's no no-no here: you can even create the "struct page"s on demand,
and create a dummy local zone that contains them that they all point back
to. It should be trivial - nobody else cares about those pages or that
zone anyway.
AFAIK as
Hi,
On Sat, 20 Jan 2001, Linus Torvalds wrote:
But point-to-point also means that you don't get any real advantage from
doing things like device-to-device DMA. Because the links are
asynchronous, you need buffers in between them anyway, and there is no
bandwidth advantage of not going
Hi,
On Sat, 20 Jan 2001, Linus Torvalds wrote:
Now, there are things to look out for: when you do these kinds of dummy
"struct page" tricks, some macros etc WILL NOT WORK. In particular, we do
not currently have a good "page_to_bus/phys()" function. That means that
anybody trying to do DMA
Hi,
On Sat, 20 Jan 2001, Linus Torvalds wrote:
But think like a good hardware designer.
In 99% of all cases, where do you want the results of a read to end up?
Where do you want the contents of a write to come from?
Right. Memory.
Now, optimize for the common case. Make the common
Hi,
On Thu, 18 Jan 2001, Linus Torvalds wrote:
> > I agree, it's device dependent, but such hardware exists.
>
> Show me any practical case where the hardware actually exists.
http://www.augan.com
> I do not know of _any_ disk controllers that let you map the controller
> buffers over PCI.
Hi,
On Thu, 18 Jan 2001, Linus Torvalds wrote:
I agree, it's device dependent, but such hardware exists.
Show me any practical case where the hardware actually exists.
http://www.augan.com
I do not know of _any_ disk controllers that let you map the controller
buffers over PCI. Which
Hi,
On Thu, 18 Jan 2001, Linus Torvalds wrote:
> It's too damn device-dependent, and it's not worth it. There's no way to
> make it general with any current hardware, and there probably isn't going
> to be for at least another decade or so. And because it's expensive and
> slow to do even on a
Hi,
On Thu, 18 Jan 2001, Linus Torvalds wrote:
> > Actually, this is a great example, because at one point I was working
> > on a device interface which would offload all of the disk-disk copying
> > overhead to the disks themselves, and not involve the CPU/RAM at all.
>
> It's a horrible
Hi,
On Thu, 18 Jan 2001, Linus Torvalds wrote:
Actually, this is a great example, because at one point I was working
on a device interface which would offload all of the disk-disk copying
overhead to the disks themselves, and not involve the CPU/RAM at all.
It's a horrible example.
Hi,
On Thu, 18 Jan 2001, Linus Torvalds wrote:
It's too damn device-dependent, and it's not worth it. There's no way to
make it general with any current hardware, and there probably isn't going
to be for at least another decade or so. And because it's expensive and
slow to do even on a
Hi,
On Thu, 18 Jan 2001, Andrew Morton wrote:
> - Get rid of the special printk buffer - share the
> log buffer. (Implies writes to console
> devices will be broken into two writes when they
> wrap around).
> - Teach vsprintf to print into a circular buffer
> (snprintf thus comes for
Hi,
On Thu, 18 Jan 2001, Andrew Morton wrote:
- Get rid of the special printk buffer - share the
log buffer. (Implies writes to console
devices will be broken into two writes when they
wrap around).
- Teach vsprintf to print into a circular buffer
(snprintf thus comes for free).
Hi,
On Tue, 2 Jan 2001, David S. Miller wrote:
>We really can't. We _only_ have load-and-zero. And it has to be
>16-byte aligned. xchg() is just not something the CPU implements.
>
> Oh bugger... you do have real problems.
For 2.5 we could move all the atomic functions from
Hi,
On Tue, 2 Jan 2001, Alexander Viro wrote:
> Depends on a filesystem. Generally you don't want asynchronous operations
> to grab semaphores shared with something else. kswapd knows to skip the locked
> pages, but that's it - if writepage() is going to block on a semaphore you
> will not know
Hi,
On Tue, 2 Jan 2001, Alexander Viro wrote:
Depends on a filesystem. Generally you don't want asynchronous operations
to grab semaphores shared with something else. kswapd knows to skip the locked
pages, but that's it - if writepage() is going to block on a semaphore you
will not know
Hi,
On Tue, 2 Jan 2001, David S. Miller wrote:
We really can't. We _only_ have load-and-zero. And it has to be
16-byte aligned. xchg() is just not something the CPU implements.
Oh bugger... you do have real problems.
For 2.5 we could move all the atomic functions from atomic.h,
Hi,
On Mon, 1 Jan 2001, Alexander Viro wrote:
> But... But with AFFS you _have_ exclusion between block-allocation and
> truncate(). It has no sparse files, so pageout will never allocate
> anything. I.e. all allocations come from write(2). And both write(2) and
> truncate(2) hold i_sem.
>
>
901 - 1000 of 1055 matches
Mail list logo
