Greg KH writes:
> I do care about this, please don't think that. But here's my reasoning
> for why it needs to go:
[...]
> - original developer of devfs has publicly stated udev is a
> replacement.
Well, that's news to me!
> - policy in the kernel.
Like sysfs :-)
> -
Greg KH writes:
I do care about this, please don't think that. But here's my reasoning
for why it needs to go:
[...]
- original developer of devfs has publicly stated udev is a
replacement.
Well, that's news to me!
- policy in the kernel.
Like sysfs :-)
-
Linus Torvalds writes:
>
> On Thu, 19 Jul 2001, Richard Gooch wrote:
> > Linus Torvalds writes:
> > > Note that the unfair aging (apart from just being a natural
> > > requirement of higher allocation pressure) actually has some other
> > > advantages too:
Linus Torvalds writes:
> Note that the unfair aging (apart from just being a natural
> requirement of higher allocation pressure) actually has some other
> advantages too: it ends up being aload balancing thing. Sure, it
> might throw out some things that get "unfairly" treated, but once we
>
Linus Torvalds writes:
Note that the unfair aging (apart from just being a natural
requirement of higher allocation pressure) actually has some other
advantages too: it ends up being aload balancing thing. Sure, it
might throw out some things that get unfairly treated, but once we
bring them
Linus Torvalds writes:
On Thu, 19 Jul 2001, Richard Gooch wrote:
Linus Torvalds writes:
Note that the unfair aging (apart from just being a natural
requirement of higher allocation pressure) actually has some other
advantages too: it ends up being aload balancing thing. Sure
Alexander Viro writes:
>
>
> On Sun, 24 Jun 2001, Marty Leisner wrote:
>
> > I just installed redhat 7.1 on a system.
> >
> > Cleaning up, a made a fs for home...(mounted on /mnt
> > to write the stuff to it)
> >
> > Then I accidently mounted it on /home.
> >
> > So it was mounted on /home
Gregory T. Norris writes:
>
> --qlTNgmc+xy1dBmNv
> Content-Type: multipart/mixed; boundary="0F1p//8PRICkK4MW"
> Content-Disposition: inline
Yuk! MIME!
> --0F1p//8PRICkK4MW
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
Gregory T. Norris writes:
--qlTNgmc+xy1dBmNv
Content-Type: multipart/mixed; boundary=0F1p//8PRICkK4MW
Content-Disposition: inline
Yuk! MIME!
--0F1p//8PRICkK4MW
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Horrors!
Alexander Viro writes:
On Sun, 24 Jun 2001, Marty Leisner wrote:
I just installed redhat 7.1 on a system.
Cleaning up, a made a fs for home...(mounted on /mnt
to write the stuff to it)
Then I accidently mounted it on /home.
So it was mounted on /home and /mnt at the same
Alexander Viro writes:
> BTW, proc_net_create() is also not a good idea if you block the
> interrupts. Ditto for netlink_kernel_create(), AFAICS (due to
> netlink_kernel_creat() -> sock_alloc() -> get_empty_inode() ->
> kmem_cache_alloc() with SLAB_KERNEL).
>
> That, BTW, is a nice illustration
Alexander Viro writes:
BTW, proc_net_create() is also not a good idea if you block the
interrupts. Ditto for netlink_kernel_create(), AFAICS (due to
netlink_kernel_creat() - sock_alloc() - get_empty_inode() -
kmem_cache_alloc() with SLAB_KERNEL).
That, BTW, is a nice illustration - it's
Larry McVoy writes:
> On Wed, Jun 20, 2001 at 11:09:10PM +0100, Alan Cox wrote:
> > > http://www.zdnet.com/zdnn/stories/news/0,4586,5092935,00.html >
> >
> > Of course the URL that goes with that is :
> > http://www.microsoft.com/windows2000/interix/features.asp
> >
> > Yes., Microsoft
Daniel Phillips writes:
> On Wednesday 20 June 2001 06:39, Richard Gooch wrote:
> > Starting I/O immediately if there is no load sounds nice. However,
> > what about the other case, when the disc is already spun down (and
> > hence there's no I/O load either)? I want the
Daniel Phillips writes:
On Wednesday 20 June 2001 06:39, Richard Gooch wrote:
Starting I/O immediately if there is no load sounds nice. However,
what about the other case, when the disc is already spun down (and
hence there's no I/O load either)? I want the system to avoid doing
writes
Larry McVoy writes:
On Wed, Jun 20, 2001 at 11:09:10PM +0100, Alan Cox wrote:
http://www.zdnet.com/zdnn/stories/news/0,4586,5092935,00.html
Of course the URL that goes with that is :
http://www.microsoft.com/windows2000/interix/features.asp
Yes., Microsoft ship GNU C (quite
Daniel Phillips writes:
> I never realized how much I didn't like the good old 5 second delay
> between saving an edit and actually getting it written to disk until
> it went away. Now the question is, did I lose any performance in
> doing that. What I wrote in the previous email turned out to
Hi, Al. Here's an oddity I just ran across with VFS bindings:
# mkfifo /dev/modem (BTW: it would be nice not to have to make the node)
# mount --bind /dev/tts/0 /dev/modem
# kermit
kermit> set line /dev/modem
kermit> set speed 4800
?Sorry, you must SET LINE first
The reason this is
Larry McVoy writes:
> Great, then we are in violent agreement on the single abstraction.
> On the second part, I stand by my previous statements that threads or
> processes should be used sparingly.
>
> All I'm doing is trying to counter all the "threads are great" hype.
> This is a pretty
Larry McVoy writes:
Great, then we are in violent agreement on the single abstraction.
On the second part, I stand by my previous statements that threads or
processes should be used sparingly.
All I'm doing is trying to counter all the threads are great hype.
This is a pretty intelligent
Hi, Al. Here's an oddity I just ran across with VFS bindings:
# mkfifo /dev/modem (BTW: it would be nice not to have to make the node)
# mount --bind /dev/tts/0 /dev/modem
# kermit
kermit set line /dev/modem
kermit set speed 4800
?Sorry, you must SET LINE first
The reason this is happening
Daniel Phillips writes:
I never realized how much I didn't like the good old 5 second delay
between saving an edit and actually getting it written to disk until
it went away. Now the question is, did I lose any performance in
doing that. What I wrote in the previous email turned out to be
Alexander Viro writes:
>
>
> On Mon, 18 Jun 2001, Richard Gooch wrote:
>
> > > Irrelevant. BKL provides an exclusion only on non-blocking areas.
> >
> > Yeah, I know all that.
>
> So what the hell are you talking about?
Never mind. We seem to be talk
Alexander Viro writes:
> On Mon, 18 Jun 2001, Richard Gooch wrote:
> > Alexander Viro writes:
> > > On Mon, 18 Jun 2001, Richard Gooch wrote:
> > > > - Widened locking in and
> > >
> > > No, you hadn't. Both vfs_readlink() and vfs_follow_link() a
Alexander Viro writes:
>
>
> On Mon, 18 Jun 2001, Richard Gooch wrote:
>
> > - Widened locking in and
>
> No, you hadn't. Both vfs_readlink() and vfs_follow_link() are blocking
> functions, so BKL is worthless there.
Huh? The BKL will protect against other o
Alexander Viro writes:
On Mon, 18 Jun 2001, Richard Gooch wrote:
- Widened locking in devfs_readlink and devfs_follow_link
No, you hadn't. Both vfs_readlink() and vfs_follow_link() are blocking
functions, so BKL is worthless there.
Huh? The BKL will protect against other operations
Alexander Viro writes:
On Mon, 18 Jun 2001, Richard Gooch wrote:
Alexander Viro writes:
On Mon, 18 Jun 2001, Richard Gooch wrote:
- Widened locking in devfs_readlink and devfs_follow_link
No, you hadn't. Both vfs_readlink() and vfs_follow_link() are blocking
functions, so BKL
Alexander Viro writes:
On Mon, 18 Jun 2001, Richard Gooch wrote:
Irrelevant. BKL provides an exclusion only on non-blocking areas.
Yeah, I know all that.
So what the hell are you talking about?
Never mind. We seem to be talking at cross purposes. We both know how
the BKL works
Hi, all. Version 181 of my devfs patch is now available from:
http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html
The devfs FAQ is also available here.
Patch directly available from:
ftp://ftp.??.kernel.org/pub/linux/kernel/people/rgooch/v2.4/devfs-patch-current.gz
AND:
Hi, all. Version 181 of my devfs patch is now available from:
http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html
The devfs FAQ is also available here.
Patch directly available from:
ftp://ftp.??.kernel.org/pub/linux/kernel/people/rgooch/v2.4/devfs-patch-current.gz
AND:
Daniel Dickman writes:
> Here is a small patch to main.c.
>
> It does the following:
> - makes sure that asm/mtrr.h actually gets included, and
What the hell is this? It is already included!
> - changes formatting in one place as per Documentation/CodingStyle
>
> --- linux-2.4.5/init/main.c
Daniel Dickman writes:
Here is a small patch to main.c.
It does the following:
- makes sure that asm/mtrr.h actually gets included, and
What the hell is this? It is already included!
- changes formatting in one place as per Documentation/CodingStyle
--- linux-2.4.5/init/main.c Tue
Daniel Phillips writes:
> On Thursday 14 June 2001 10:34, Alexander Viro wrote:
> > On Thu, 14 Jun 2001, Daniel Phillips wrote:
> > > This sounds a lot like apt-get, doesn't it?
> >
> > Folks, RTFFAQ, please. URL is attached to the end of each posting.
>
> The FAQ blesses the idea of people
Daniel Phillips writes:
On Thursday 14 June 2001 10:34, Alexander Viro wrote:
On Thu, 14 Jun 2001, Daniel Phillips wrote:
This sounds a lot like apt-get, doesn't it?
Folks, RTFFAQ, please. URL is attached to the end of each posting.
The FAQ blesses the idea of people setting up
Hi, all. Version 180 of my devfs patch is now available from:
http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html
The devfs FAQ is also available here.
Patch directly available from:
ftp://ftp.??.kernel.org/pub/linux/kernel/people/rgooch/v2.4/devfs-patch-current.gz
AND:
Hi, all. Version 180 of my devfs patch is now available from:
http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html
The devfs FAQ is also available here.
Patch directly available from:
ftp://ftp.??.kernel.org/pub/linux/kernel/people/rgooch/v2.4/devfs-patch-current.gz
AND:
Jeff Garzik writes:
> Richard Gooch wrote:
> >
> > Jeff Garzik writes:
> > >
> > > I'm sorry but this is a regression, plain and simple.
> > >
> > > Previous versons of Linux have worked great on diskless workstations
> > > with NO
Jeff Garzik writes:
>
> I'm sorry but this is a regression, plain and simple.
>
> Previous versons of Linux have worked great on diskless workstations
> with NO swap.
>
> Swap is "extra space to be used if we have it" and nothing else.
Sure. But Linux still works without swap. It's just that
Daniel Phillips writes:
> On Wednesday 06 June 2001 10:54, Sean Hunter wrote:
>
> > > Did you try to put twice as much swap as you have RAM ? (e.g. add a
> > > 512M swapfile to your box)
> > > This is what Linus recommended for 2.4 (swap = 2 * RAM), saying
> > > that anything less won't do any
Daniel Phillips writes:
On Wednesday 06 June 2001 10:54, Sean Hunter wrote:
Did you try to put twice as much swap as you have RAM ? (e.g. add a
512M swapfile to your box)
This is what Linus recommended for 2.4 (swap = 2 * RAM), saying
that anything less won't do any good: 2.4
Jeff Garzik writes:
I'm sorry but this is a regression, plain and simple.
Previous versons of Linux have worked great on diskless workstations
with NO swap.
Swap is extra space to be used if we have it and nothing else.
Sure. But Linux still works without swap. It's just that if you
Jeff Garzik writes:
Richard Gooch wrote:
Jeff Garzik writes:
I'm sorry but this is a regression, plain and simple.
Previous versons of Linux have worked great on diskless workstations
with NO swap.
Swap is extra space to be used if we have it and nothing else.
Sure
Hi, all. Version 179 of my devfs patch is now available from:
http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html
The devfs FAQ is also available here.
Patch directly available from:
ftp://ftp.??.kernel.org/pub/linux/kernel/people/rgooch/v2.4/devfs-patch-current.gz
AND:
Hi, all. Version 179 of my devfs patch is now available from:
http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html
The devfs FAQ is also available here.
Patch directly available from:
ftp://ftp.??.kernel.org/pub/linux/kernel/people/rgooch/v2.4/devfs-patch-current.gz
AND:
Hi, all. Version 178 of my devfs patch is now available from:
http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html
The devfs FAQ is also available here.
Patch directly available from:
ftp://ftp.??.kernel.org/pub/linux/kernel/people/rgooch/v2.4/devfs-patch-current.gz
AND:
Hi, all. Version 178 of my devfs patch is now available from:
http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html
The devfs FAQ is also available here.
Patch directly available from:
ftp://ftp.??.kernel.org/pub/linux/kernel/people/rgooch/v2.4/devfs-patch-current.gz
AND:
Hi, all. Version 177 of my devfs patch is now available from:
http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html
The devfs FAQ is also available here.
Patch directly available from:
ftp://ftp.??.kernel.org/pub/linux/kernel/people/rgooch/v2.4/devfs-patch-current.gz
AND:
Akash Jain writes:
> hello,
>
> in fs/devfs/base.c,
> the struct devfsd_notify_struct is approx 1056 bytes, allocating it
> on a stack of 8k seems unreasonable. here we simply move it to the
> heap, i don't think it is a _must_ be on stack type thing
I absolutely don't want this patch applied.
Akash Jain writes:
hello,
in fs/devfs/base.c,
the struct devfsd_notify_struct is approx 1056 bytes, allocating it
on a stack of 8k seems unreasonable. here we simply move it to the
heap, i don't think it is a _must_ be on stack type thing
I absolutely don't want this patch applied. It's
Tony Hoyle writes:
> Richard Gooch wrote:
>
> > In fact, hopefully he's still in a dark mood, and he may take up the
> > suggestion to bounce mails of the following type:
> > - MIME encoded
> > - HTML encoded
> > - quoted printables (those stupid "=20&q
Matti Aarnio writes:
> On Tue, May 22, 2001 at 09:06:25AM -0400, Richard Gooch wrote:
> ...
> > 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
Brent D. Norris writes:
> > I veto, the whole point of moving to ECN was to make a statement and
> > get people to fix their kit.
> >
> > We will remove these people, that's all.
>
> Isn't this a problem though because the messge saying that ECN was
> enabled was set after ECN was enabled? Thus
Alan Cox writes:
> > Matti Aarnio writes:
> > > I am contemplating to periodically turn off the ECN bit to
> > > let email out, but DaveM has veto there.
> >
> > I veto, the whole point of moving to ECN was to make a statement and
> > get people to fix their kit.
> >
> > We will remove these
Matti Aarnio writes:
On Tue, May 22, 2001 at 09:06:25AM -0400, Richard Gooch wrote:
...
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
Tony Hoyle writes:
Richard Gooch wrote:
In fact, hopefully he's still in a dark mood, and he may take up the
suggestion to bounce mails of the following type:
- MIME encoded
- HTML encoded
- quoted printables (those stupid =20 things are particuarly hard to
read).
Surely it'd
Brent D. Norris writes:
I veto, the whole point of moving to ECN was to make a statement and
get people to fix their kit.
We will remove these people, that's all.
Isn't this a problem though because the messge saying that ECN was
enabled was set after ECN was enabled? Thus these
Alan Cox writes:
Matti Aarnio writes:
I am contemplating to periodically turn off the ECN bit to
let email out, but DaveM has veto there.
I veto, the whole point of moving to ECN was to make a statement and
get people to fix their kit.
We will remove these people, that's
Ph. Marek writes:
> in fs/devfs/util.c is
> void __init devfs_make_root (const char *name)
> which is wrong as pivot_root allows changing the root-device in the runtime.
>
> I think it should be
> void __init devfs_make_root (const char *name)
> and get called by
> fs/super.c:
>
Ph. Marek writes:
in fs/devfs/util.c is
void __init devfs_make_root (const char *name)
which is wrong as pivot_root allows changing the root-device in the runtime.
I think it should be
void __init devfs_make_root (const char *name)
and get called by
fs/super.c:
Alexander Viro writes:
>
>
> On Sat, 19 May 2001, Richard Gooch wrote:
>
> > The transaction(2) syscall can be just as easily abused as ioctl(2) in
> > this respect. People can pass pointers to ill-designed structures very
>
> Right. Moreover, it's not need
Matthew Wilcox writes:
> On Sat, May 19, 2001 at 12:51:23PM -0600, Richard Gooch wrote:
> > Al, if you really want to kill ioctl(2), then perhaps you should
> > implement a transaction(2) syscall. Something like:
> > int transaction (int fd, void *rbuf, size_t rlen,
>
Andries Brouwer writes:
> Andrew Morton writes:
>
> > > (2) what about bootstrapping? how do you find the root device?
> > > Do you do "root=/dev/hda/offset=63,limit=1235823"? Bit nasty.
> >
> > Ben's patch makes initrd mandatory.
>
> Can this be fixed? I've *never* had
Alan Cox writes:
> > ioctls are evil, period. At least with these names you can use normal
> > scripting and don't need any special tools. Every ioctl means a binary
> > that has no business to exist.
>
> That is not IMHO a rational argument. It isn't my fault that your
> shell does not support
Alexander Viro writes:
On Sat, 19 May 2001, Richard Gooch wrote:
The transaction(2) syscall can be just as easily abused as ioctl(2) in
this respect. People can pass pointers to ill-designed structures very
Right. Moreover, it's not needed. The same functionality can be
trivially
Matthew Wilcox writes:
On Sat, May 19, 2001 at 12:51:23PM -0600, Richard Gooch wrote:
Al, if you really want to kill ioctl(2), then perhaps you should
implement a transaction(2) syscall. Something like:
int transaction (int fd, void *rbuf, size_t rlen,
void *wbuf
Andries Brouwer writes:
Andrew Morton writes:
(2) what about bootstrapping? how do you find the root device?
Do you do root=/dev/hda/offset=63,limit=1235823? Bit nasty.
Ben's patch makes initrd mandatory.
Can this be fixed? I've *never* had to futz with
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) {
>
> drivers/kitchen/bluetooth/vegerack/cd
>
>
[Cc: list trimmed because I figure people are getting tired of us:-]
H. Peter Anvin writes:
> Richard Gooch wrote:
> >
> > H. Peter Anvin writes:
> > > Richard Gooch wrote:
> > > >
> > > > Erm, let's start again. My central point is that you ca
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 t
H. Peter Anvin writes:
> Richard Gooch wrote:
> > We have this aliasing anyway. sg and sr are just one example. If you
> > care about conflicts, then make sure the drivers lock each other out.
> > It's got nothing to do with the mechanism to find out whether
> > somethi
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 this funny
H. Peter Anvin writes:
> 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 poi
Linus Torvalds writes:
>
> On Wed, 16 May 2001, Richard Gooch wrote:
> > >
> > > This is still a really bad idea. You don't want to tie this kind of
> > > things to the name.
> >
> > Why do you think it's a bad idea?
>
> Well, one r
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 (bu
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) {
> > > &
Andrzej Krzysztofowicz writes:
> >
> > OK, just correct me if I get this wrong, but this code is taking the LAST 2
> > characters of the device name and verifying that it is "cd". Which would
> > mean that the standard states that "/dev/ginsucd" would be a CD-ROM drive?
> >
> > That is why I
Andrzej Krzysztofowicz writes:
OK, just correct me if I get this wrong, but this code is taking the LAST 2
characters of the device name and verifying that it is cd. Which would
mean that the standard states that /dev/ginsucd would be a CD-ROM drive?
That is why I feel a name of a
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);
exit (1
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) {
This is still a really
Linus Torvalds writes:
On Wed, 16 May 2001, Richard Gooch wrote:
This is still a really bad idea. You don't want to tie this kind of
things to the name.
Why do you think it's a bad idea?
Well, one reason names are bad is that they don't always exist.
If you only have
H. Peter Anvin writes:
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
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 this funny aliasing, you get
H. Peter Anvin writes:
Richard Gooch wrote:
We have this aliasing anyway. sg and sr are just one example. If you
care about conflicts, then make sure the drivers lock each other out.
It's got nothing to do with the mechanism to find out whether
something can behave like a CD-ROM
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 the
notion that you need to reserve
[Cc: list trimmed because I figure people are getting tired of us:-]
H. Peter Anvin writes:
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
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) {
drivers/kitchen/bluetooth/vegerack/cd
its the cabbage
Alan Cox writes:
> > > > if (strcmp (buffer + len - 2, "cd") != 0) {
> > > > fprintf (stderr, "Not a CD-ROM! Bugger off.\n");
> > > > exit (1);
> > >
> > > And on my box cd is the cabbage dicer whoops
> >
> > Actually, no, because it's guaranteed that a
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) {
> &g
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");
> > exit (1);
>
> And on my box cd is the cabbage dicer whoops
Actually, no, because it's
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 ...
>
> with
>
>if
Linus Torvalds writes:
>
> On Tue, 15 May 2001, Richard Gooch wrote:
> >
> > However, what about simply invalidating an entry in the buffer cache
> > when you do a write from the page cache?
>
> And how do you do the invalidate the other way, pray tell?
>
>
Linus Torvalds writes:
> You could choose to do "partial coherency", ie be coherent only one
> way, for example. That would make the coherency overhead much less,
> but would also make the caches basically act very unpredictably -
> you might have somebody write through the page cache yet on a
Linus Torvalds writes:
You could choose to do partial coherency, ie be coherent only one
way, for example. That would make the coherency overhead much less,
but would also make the caches basically act very unpredictably -
you might have somebody write through the page cache yet on a read
Linus Torvalds writes:
On Tue, 15 May 2001, Richard Gooch wrote:
However, what about simply invalidating an entry in the buffer cache
when you do a write from the page cache?
And how do you do the invalidate the other way, pray tell?
What happens if you create a buffer cache entry
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 ...
with
if
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);
exit (1);
And on my box cd is the cabbage dicer whoops
Actually, no, because it's guaranteed that a
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 off.\n);
exit
Alan Cox writes:
if (strcmp (buffer + len - 2, cd) != 0) {
fprintf (stderr, Not a CD-ROM! Bugger off.\n);
exit (1);
And on my box cd is the cabbage dicer whoops
Actually, no, because it's guaranteed that a trailing /cd is a
CD-ROM.
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
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
1 - 100 of 264 matches
Mail list logo
