On Wed, 10 Jan 2001, Andrea Arcangeli wrote:
Do we have enough protection to ensure this for other filesystems?
Note that this has nothing to do with `rmdir .`. You will run into the
mentioned issue just now with '''rmdir "`pwd`"'''. I've not checked
the other fses but I would put such
On Wed, 10 Jan 2001, Chris Mason wrote:
On Wednesday, January 10, 2001 12:47:17 AM -0500 Alexander Viro
[EMAIL PROTECTED] wrote:
However, actual code really looks like the end of filldir(). If that's the
case we are deep in it - argument of filldir() gets screwed. buf
On Wed, 10 Jan 2001, Chris Mason wrote:
Ah thanks, that makes more sense. But, copy_to_user is only working on
namelen bytes, and reclen is bigger than that. So, who is checking the
value for the buf-current_dir pointer?
Look at the thing again. Especially at the place where reclen is
Patch updates filesystems/Locking - corrects -writepage()
prototype, removes dead vma methods and corrects -writepage() and
-readpage() description wrt page lock.
Please, apply.
diff -urN S1-pre1/Documentation/filesystems/Locking
S1-pre1-s_lock/Documentation/filesystems/Locking
On Thu, 11 Jan 2001, Daniel Phillips wrote:
"Udo A. Steinberg" wrote:
Upon fscking after reboot, I always have errors on a
single inode and it's always the same one:
/dev/hdb1: Inode 522901, i_blocks is 64, should be 8. FIXED
Can someone tell me an easy and reliable way of
On Thu, 11 Jan 2001, Stephen C. Tweedie wrote:
Hi,
On Wed, Jan 10, 2001 at 12:11:16PM -0800, Linus Torvalds wrote:
That said, we can easily support the notion of CLONE_CRED if we absolutely
have to (and sane people just shouldn't use it), so if somebody wants to
work on this for
On Thu, 11 Jan 2001, Stephen C. Tweedie wrote:
Hi,
On Thu, Jan 11, 2001 at 02:12:05PM +0100, Trond Myklebust wrote:
What's wrong with copy-on-write style semantics? IOW, anyone who
wants to change the credentials needs to make a private copy of the
existing structure first.
On Thu, 11 Jan 2001, Stephen C. Tweedie wrote:
And how is that different from the current situation?
It's not, which is the point I was making: COW doesn't actually solve
the pthreads problem. Far better to do it in user space.
Oh, certainly. We need COW for completely unrelated
On Thu, 11 Jan 2001, Udo A. Steinberg wrote:
/dev/hdb1: Inode 522901, i_blocks is 64, should be 8. FIXED
umount: none busy - remounted read-only
The "none" bit puzzles me the most. /etc/fstab and /etc/mtab
look perfectly ok.
Has anyone got an idea? Everything worked well with 2.4.0
rpc_release_task is required by nfs.o.
--- net/sunrpc/sunrpc_syms.cFri Apr 21 19:08:52 2000
+++ net/sunrpc/sunrpc_syms.cThu Jan 11 18:01:50 2001
@@ -36,6 +36,7 @@
EXPORT_SYMBOL(rpciod_up);
EXPORT_SYMBOL(rpc_new_task);
EXPORT_SYMBOL(rpc_wake_up_status);
On Fri, 12 Jan 2001, Chris Mason wrote:
Hi guys,
This code for generic_file_write calls vmtruncate without i_sem held. Is
that intentional? It should cause problems for reiserfs at least...
Erm... generic_file_write() grabs i_sem upon entry and drops it on exit.
This call of
On Thu, 10 May 2001, Jonathan Lundell wrote:
ENOTTY is used by several non-serial devices (or file systems) to
object to an unrecognized ioctl command. There's also ENOIOCTLCMD
(apparently supposed to be a non-user errno, but i don't see where it
gets changed to something else) and
On Fri, 11 May 2001, Andreas Dilger wrote:
I've tested again, now with kdb, and the system loops in ext2_find_entry()
or ext2_add_link(), because there is a directory with a zero rec_len.
While the actual cause of this problem is elsewhere, the fact that
ext2_next_entry() will loop
On Mon, 7 May 2001, Pavel Machek wrote:
OTOH with current way if you make mistake in kernel, fsck will not
automatically inherit it; therefore fsck is likely to work even if
kernel ext2 is b0rken [and that's fairly important]
... and by the same logics you should make fsck implement its own
On Sat, 12 May 2001, Andreas Dilger wrote:
We could use the buffer_uptodate flag on the buffer to signal that
the block has been checked. AFAIK, a new buffer will not be uptodate,
and once it is it will not be read from disk again... However, if a
user-space process read the buffer would
On Sun, 13 May 2001, BERECZ Szabolcs wrote:
Hi!
root@kama3:/home/szabi# cat /proc/mounts
...
/dev/hdb2 /usr ext2 rw 0 0
...
root@kama3:/home/szabi# swapon /dev/hdb2
- Doctor, it hurts when I do it!
- Don't do it, then.
Just what behaviour had you expected?
-
To unsubscribe from this
On Sun, 13 May 2001, BERECZ Szabolcs wrote:
On Sat, 12 May 2001, Alexander Viro wrote:
- Doctor, it hurts when I do it!
- Don't do it, then.
Just what behaviour had you expected?
maybe that I don't have to shutdown?
I think it's a *bad* behaviour
Erm... Let me restate: what did
On Sun, 13 May 2001, Alan Cox wrote:
root@kama3:/home/szabi# cat /proc/mounts
/dev/hdb2 /usr ext2 rw 0 0
root@kama3:/home/szabi# swapon /dev/hdb2
- Doctor, it hurts when I do it!
- Don't do it, then.
Just what behaviour had you expected?
EBUSY would be somewhat nicer.
On Mon, 14 May 2001, Andreas Dilger wrote:
Just to clarify, this means that the inode numbers reported by an
msdos filesystem are a function of the disk-layout itself (i.e. they
are determined at mount time), and not numbers created when the file
is first accessed (AFAIK).
Wrong. open
On Mon, 14 May 2001, H. Peter Anvin wrote:
Correct. At least at one time it used the offset of the directory entry
when that particular inode was last seen by the kernel... meaning that
when it finally dropped out of the inode cache, it would change inode
numbers. I thought that was a
On Mon, 14 May 2001, Alan Cox wrote:
Abstract device file systems are beautiful concepts but they don't solve
the device name space problem and they introduce hideous incompatibilities
with existing software.
let me get it straight. You are talking about software that would be
a)
On Mon, 14 May 2001, Alan Cox wrote:
Would you mind demonstrating such wonder? Old devices are still there,
AFAICS. Ext2 (reiserfs, devfs, abortion-of-your-choice-fs) still has
the ability to create device nodes for them.
Except that Linus wont hand out major numbers, which means I
On Mon, 14 May 2001, Alan Cox wrote:
Except that Linus wont hand out major numbers, which means I can't even boot
simply off such a device. I bet the vendors in question dont think the sun
shines out of linus backside any more.
Not really. Special-casing for mounting root is
On Mon, 14 May 2001, H. Peter Anvin wrote:
LILO uses BIOS, for fsck sake. It couldn't care less for device numbers
on the kernel side. Ask Andries how much do they have in common with
BIOS drive numbers.
That's not the issue. LILO takes whatever you pass to root= and converts
it
On Mon, 14 May 2001, Alan Cox wrote:
grep MAJOR lilo-21.4.4/*|wc -l
323
/me looks and barfs.
Alan, had you actually looked at it? It will require massive changes
whenever you introduce new major. And most of such areas are stuff
that doesn't matter for new devices anyway - geometry,
On Mon, 14 May 2001, Alan Cox wrote:
Oh, _that_ one. shrug pass rootname=driver!name (or whatever syntax
you prefer) to the kernel and call do_mount() instead of sys_mknod() in
prepare_namespace() (rootfs patch). BFD.
Yet another 2.5 project. If Linus wants to go play with name driven
On Mon, 14 May 2001, Larry McVoy wrote:
Hell, that's the OS that gave us mmap, remember that?
I got it from Agnes...
Don't get me wrong, SunOS 4 was probably the nicest thing Sun had ever
released and I love it, but mmap(2) was _not_ the best of ideas. Files
as streams of bytes and files
On Mon, 14 May 2001, Linus Torvalds wrote:
The current page cache is completely non-coherent (with _anything_: it's
not coherent with other files using a page cache because they have a
different index, and it's not coherent with the buffer cache because that
one isn't even in the same name
On Tue, 15 May 2001, Richard Gooch wrote:
What happens if you create a buffer cache entry? Does that
invalidate the page cache one? Or do you just allow invalidates one
way, and not the other? And why=
I just figured on one way invalidates, because that seems cheap and
easy and has
On 15 May 2001, Blesson Paul wrote:
Hi
In everyfile system, dget() function is called. But I cannot find
where is the dget() function is written. Where is it
man grep
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
On Tue, 15 May 2001, Linus Torvalds wrote:
Looks like there are 19 filesystems that use the buffer cache right now:
grep -l bread fs/*/*.c | cut -d/ -f2 | sort -u | wc
So quite a bit of work involved.
UNIX-like ones (and that includes QNX) are easy. HFS is hopeless - it won't
be
On Tue, 15 May 2001, Alan Cox wrote:
to
/* Use scsi if possible [scsi, ide-scsi, usb-scsi, ...] */
if(HAS_FEATURE_SET(fd, scsi-tape))
...
else if(HAS_FEATURE_SET(fd, floppy-tape))
..
Alan, if we are doing that we might as well use saner
On Tue, 15 May 2001, Alan Cox wrote:
Alan, if we are doing that we might as well use saner interface than
ioctl(2). In case you've mentioned we don't want make device SYS$FOO17
do special action OP$LOUD$BARF4269. We want make device rewind the tape.
Or tell us geometry. Or eject the
On Tue, 15 May 2001, Daniel Phillips wrote:
That's because you left out his invalidate:
* create an instance in pagecache
* start reading into buffer cache (doesn't invalidate, right?)
* start writing using pagecache (invalidate buffer copy)
Bzzert. You have a race
On Tue, 15 May 2001, Linus Torvalds wrote:
What is the horrible app that does something like this?
eject(1), for one thing. And yes, it's ugly beyond belief - don't read
without a barfbag. BTW, LILO is not better, to put it _very_ mildly.
/* Use scsi if possible [scsi, ide-scsi,
On Tue, 15 May 2001, Alexander Viro wrote:
On Tue, 15 May 2001, Alexander Viro wrote:
ramdisks, etc.). Besides, it allows to start turning functions called
from device_init() into initcalls, thus getting rid of ifdef dungpiles
in them.
... and here's the next part. Takes
On Tue, 15 May 2001, James Simmons wrote:
I would use write except we use write to draw into the framebuffer. If I
write to the framebuffer with that data the only thing that will happen is
I will get pretty colors on my screen.
Yes. And we also use write to send data to printer. So what?
On Tue, 15 May 2001, James Simmons wrote:
What I wish was done was the very first ioctl call was a generic ioctl
call to pass driver specific data. Basically you have something like this:
struct fb_driver_specific_data {
__u32 magic_identifier;
__u32 size_of_data_packet;
On Tue, 15 May 2001, James Simmons wrote:
Well creating a new device wouldn't make linus happen right now. I do
agree ioctl calls are evil You only have X amount of them. With write
you can have infinte amounts of different functions to perform on a
device. I didn't design fbdev :-( If
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 ?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
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, O_RDWR);
Yipes!! I have to say
On Tue, 15 May 2001, H. Peter Anvin wrote:
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
On Tue, 15 May 2001, H. Peter Anvin wrote:
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
On Tue, 15 May 2001, H. Peter Anvin wrote:
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
On Tue, 15 May 2001, H. Peter Anvin wrote:
Permission management. The permissions on the subnodes are inherited
from the main node, which is stored on a persistent medium.
If you want them all to inherit it - inherit from mountpoint. End of story.
Yes, it means that permission(9) will need
On 15 May 2001, Kai Henningsen wrote:
[EMAIL PROTECTED] (Alexander Viro) wrote on 15.05.01 in
[EMAIL PROTECTED]:
... and Multics had all access to files through equivalent of mmap()
in 60s. Segments in ls(1) got that name for a good reason.
Where's something called segments
On Tue, 15 May 2001, Alexander Viro wrote:
On 15 May 2001, Kai Henningsen wrote:
[EMAIL PROTECTED] (Alexander Viro) wrote on 15.05.01 in
[EMAIL PROTECTED]:
... and Multics had all access to files through equivalent of mmap()
in 60s. Segments in ls(1) got that name for a good
On Tue, 15 May 2001, Timothy A. Seufert wrote:
Why not take it a step further than just devices? This is a perfect
model for supporting named forks.
Because unlike devices you need to be able to tar the tree up, copy it,
edit, etc.
Please, don't mix _that_ flamewar into the thread, OK?
-
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);
And on my box cd is the cabbage dicer whoops
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 where the file came from? Sure.
-
Patch turns s_lock+s_wait combination into semaphore.
wait_on_super() is dead. lock_super() is down(sb-s_lock),
unlock_super() is up(...).
One place is still ugly - get_super(), but that'll have to
wait until we add reference counters on superblocks. For the time being
On Tue, 15 May 2001, Richard Gooch wrote:
MeLinus. The device name authority (Peter). Whoever. If you want
Peter to bless it, then fine. But the standard is there. Violators
will be persecuted.
Ah, standard on names in devfs? About as relevant as GOSIP...
-
To unsubscribe from this list:
On Tue, 15 May 2001, David Brownell wrote:
I suppose that for network interface names, some convention for
interface ioctls would suffice to solve that identify step. PCI
devices would return the slot_name, USB devices need something
like a patch I posted to linux-usb-devel a few months
On 16 May 2001, Kai Henningsen wrote:
[EMAIL PROTECTED] (H. Peter Anvin) wrote on 15.05.01 in
[EMAIL PROTECTED]:
Personally, I would also like to see network devices manifest in the
filesystem namespace like everything else.
Yes.
Can we have a meta-rule?
*Every* by-name
Damn.
/me writes a patch
/me tests and finds an obvious typo
/me fixes and diffs fixed (and tested) version
/me sends the original one.
My apologies. Correct patch (taken between clean tree and
result of make distclean on the tree that gave a kernel
that passes all tests) follows. Please, apply
Linus, patch is the first chunk of rootfs stuff. I've tried to
get it as small as possible - all it does is addition of absolute root
on ramfs and necessary changes to mount_root/change_root/sys_pivot_root
and follow_dotdot. Real root is mounted atop of the absolute one.
More
On 16 May 2001, Christoph Rohland wrote:
Why do you use ramfs? Most of it is duplicated in tmpfs and ramfs is a
minimal _example_ fs. There was some agreement that this should stay
so.
Because what I need is an absolute minimum. Heck, I don't even use
regular files (in the full variant of
On 16 May 2001, Christoph Rohland wrote:
cr:/speicher/src/u4ac9 $ ls -l fs/ramfs/ramfs.o
-rw-r--r--1 cr users 141452 Mai 16 19:27 fs/ramfs/ramfs.o
_What_?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
On Wed, 16 May 2001, Linus Torvalds wrote:
On Wed, 16 May 2001, Alexander Viro wrote:
Linus, patch is the first chunk of rootfs stuff. I've tried to
get it as small as possible - all it does is addition of absolute root
on ramfs and necessary changes to mount_root/change_root
Linus, please apply the patch below (device_init as initcall).
BTW, if -pre3 didn't break the init sequence I would be very surprised -
chr_dev_init() is moved _way_ past the other device initialization stuff.
Al
diff -urN
On 16 May 2001, H. Peter Anvin wrote:
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
On Wed, 16 May 2001, H. Peter Anvin wrote:
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
On Thu, 17 May 2001, Alan Cox wrote:
Linus, patch is the first chunk of rootfs stuff. I've tried to
get it as small as possible - all it does is addition of absolute root
on ramfs and necessary changes to mount_root/change_root/sys_pivot_root
and follow_dotdot. Real root is mounted
Linus, I've done a bit more cleaning the device initialization
up (beginning of chr_dev_init()) and results were, well, interesting.
a) I2C stuff got converted to module_init() nicely. That took
a lot of cruft away.
b) init order is preserved. However, that worked only
Folks, what the hell is sti(); doing in device_init()? It's
done _much_ earlier (before calibrate_delay(); in start_kernel())
and I don't see anything that would require repeating it...
Looks bogus for me... Linus?
On Thu, 17 May 2001, Kai Germaschewski wrote:
This part is not necessary. The ordering of subdir-y only has to do with
compilation ordering, not with link order. The link order for
drivers/char/* is set explicitly in the toplevel Makefile.
Oh, crap. Right you are. OK, but it means
On Thu, 17 May 2001 [EMAIL PROTECTED] wrote:
Someone complained a moment ago about the error return in unlink.
And indeed, it used to be correct but since 2.1.132 we return a
buggy (or at least non-POSIX) error for unlink(directory).
[The EISDIR is correct for rename(), and the cleanup
Alan, drivers/media/videodev.c is your code. See if you are OK
with the patch below - it switches the thing to use of module_init()
and removes the call of videodev_init() from chr_dev_init(). I.e. the
only ordering change is that videodev_init() is postponed until immediately
before the
% find . -type f -print | xargs grep -nwC1 radio_init
./drivers/char/misc.c-75-extern int ds1286_init(void);
./drivers/char/misc.c:76:extern int radio_init(void);
./drivers/char/misc.c-77-extern int pmu_device_init(void);
--
./drivers/char/misc.c-265-#ifdef CONFIG_MISC_RADIO
On Sat, 19 May 2001, Linus Torvalds wrote:
On Sat, 19 May 2001, Pavel Machek wrote:
Well, if we did something like modify(int fd, char *how), you could do
modify(0, nonblock,9600)
What you're really proposing is to make ioctl's be ASCII strings.
Which is not necessarily a
On Sat, 19 May 2001, Pavel Machek wrote:
I thought about how to do networking without sockets, and it seems to
me like this kind of modify syscall is needed, because network sockets
connect to *two* different places (one local address and one
remote). Sockets are really nasty :-(.
Pavel,
On Sun, 20 May 2001, Abramo Bagnara wrote:
I've just had a so simple to risk to be stupid idea.
To have /proc/self/fd/N/ioctl would not have the potential to suppress
ioctl needs for *all* current uses?
No, it wouldn't. For one thing, it messes the only half-decent part of
procfs. For
Linus, patch below adds an obvious helper function and converts
several places to using it. For one thing, it's cleaner, for another -
we won't have to change these places when we add refcounting on struct
superblock. Actually, it used be a part of invalidate_device() patch.
Please, apply
On Sun, 20 May 2001, Abramo Bagnara wrote:
Suppose now to have a convention that control stream are in the form:
ACTION ARGUMENTS
Then we have
echo speed 19200 /proc/self/fd/0/ioctl
instead of
stty 19200
It seems to me something different from a pile of shit ;-)
But it isn't.
On Sun, 20 May 2001 [EMAIL PROTECTED] wrote:
Getting a list of all ioctls in the tree, along with types of their arguments
would be a great start. Anyone willing to help with that?
% man 2 ioctl_list
gives a very outdated list. Collecting the present list is trivial
but
On Sun, 20 May 2001, Russell King wrote:
I still see read()/write() being a pass any crap interface. The
implementer of the target for read()/write() will probably still be
a driver which will need to decode what its given, whether its in
ASCII or binary.
And driver writers are already
On 20 May 2001, Kai Henningsen wrote:
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
On Sun, 20 May 2001, Tim Jansen wrote:
That's why I proposed using multi-stream files. With a syscall like
fd2 = open_substream(fd, somename)
You also have streams thay are related to many device nodes at once. Sorry.
you could have several control streams and also be prepared if you want
On Sun, 20 May 2001, Abramo Bagnara wrote:
It may have several. Which one?
Can you explain better this?
Example: console. You want to be able to pass font changes. I'm
less than sure that putting them on the same channel as, e.g.,
keyboard mapping changes is a good idea. We can do it,
On Sun, 20 May 2001, Abramo Bagnara wrote:
Face it, we _already_ have more than one side band.
This does not imply it's necessarily a good idea.
We are comparing
echo 9600 /proc/self/fd/0/speed (or /dev/ttyS0/speed)
echo 8 /proc/self/fd/0/bits (or /dev/ttyS0/bits)
with
echo
On Sun, 20 May 2001, [iso-8859-1] Jakob Østergaard wrote:
Face it, we _already_ have more than one side band.
Wouldn't it be natural to
write(fd, control type)
write(fd, control information)
read(fd, reply)
Only one control file for all controls a device understands
That's
On Sun, 20 May 2001, Abramo Bagnara wrote:
How about reading from them? You are forcing restriction that may make
sense in some cases, but doesn't look good for everything.
exec 3/dev/ttyS0/ioctl
exec 43
echo speed 3
cat 4
exec 3-
exec 4-
Can you make a counter example where
On Sat, 19 May 2001, Alan Cox wrote:
Now that I'm awake and refreshed, yeah, that's awful. But
echo hot-add,slot=5,device=/dev/sda /dev/md0/control *is* sane. Heck,
the system can even send back result codes that way.
Only to an English speaker. I suspect Quebec City canadians would
Folks, patch below (_completely_ untested) is a backport of
a neat stuff from namespace-patch.
It does (OK, is supposed to do) the following: make noexec, nosuid
and nodev properties of vfsmount, not superblock.
In other words, different instances of the same fs may
On Sun, 20 May 2001, Paul Fulghum wrote:
I'll be the first to admit there is some ugliness in my driver.
So will anyone here regarding his or her code. Count me in, BTW.
Could you reread the posting you are refering to?
-
To unsubscribe from this list: send the line unsubscribe
On Sun, 20 May 2001, Edgar Toernig wrote:
IMHO any similar powerful (and versatile) interface will see the same
problems. Enforcing a read/write like interface (and rejecting drivers
that pass ptrs through this interface) may give you some knowledge about
the kernel/userspace
On Sun, 20 May 2001, Linus Torvalds wrote:
How about moratorium on new ioctls in the meanwhile? Whatever we do in
fs/ioctl.c, it _will_ take time.
Ehh.. Telling people don't do that simply doesn't work. Not if they can
do it easily anyway. Things really don't get fixed unless people
On Sun, 20 May 2001, Edgar Toernig wrote:
That assumption is totally bogus. Even for regular files you have side
effects (atime); for anything else they're unpredictable.
That means only one thing: safe backups are possible only in single-user
mode. For values of safe being not triggering
On Sat, 19 May 2001, Andrew Clausen wrote:
Alexander Viro wrote:
On Sat, 19 May 2001, Andrew Clausen wrote:
(1) these issues are independent. The partition parsing could
be done in user space, today, by blkpg, if I read the code correctly
;-) (there's an ioctl for [un
On Sun, 20 May 2001, Alan Cox wrote:
Linus, as much as I'd like to agree with you, you are hopeless optimist.
90% of drivers contain code written by stupid gits.
^^^
I think thats a very arrogant and very mistaken view of the problem. 90%
of the driver are
On Sat, 19 May 2001 [EMAIL PROTECTED] wrote:
A lot of stuff relies on the fact that close(open(foo, O_RDONLY))
is a no-op. Breaking that assumption is a Bad Thing(tm).
Also here I would like to agree. Unfortunately this is false.
Opening device files often has interesting side effects.
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
implemented by write() and
On 21 May 2001, Wichert Akkerman wrote:
In article [EMAIL PROTECTED],
Mike A. Harris [EMAIL PROTECTED] wrote:
For the record, the kgcc mess you speak of was used by
Conectiva, and I believe also by debian
Debian never had that mess.
I think that Mike refers to gcc272 being used as a
On Mon, 21 May 2001, Oliver Xymoron wrote:
If you've got side channels that are of a packet nature (aka commands),
then they can all happily coexist on one device. If you've got channels
that are streams or intended for mmap, those ought to be different
devices.
Since you've been refering
On Mon, 21 May 2001, Oliver Xymoron wrote:
K - so what? I'm guessing what you want me to see is that these
implement multiple channels. Is there a reason that eia001stat couldn't be
implemented as
f=open(/dev/eia001ctl,O_RDWR);
write(f,stat\n);
status=read(f); /* returns stat foo\n
On Mon, 21 May 2001, Linus Torvalds wrote:
It shouldn't be impossible to do the same thing to ioctl numbers. Nastier,
yes. No question about it. But we don't necessarily have to redesign the
whole approach - we only want to re-design the internal kernel interfaces.
That, in turn, might
Linus, patch below adds the missing half of kdev_t -
for block devices we already have a unique pointer (struct block_device *,
inode-i_bdev) and that adds a similar animal for character devices.
That is, it adds a new structure (struct char_device) and a cache
indexed by dev_t.
On Tue, 22 May 2001, Oliver Xymoron wrote:
Because foo_ is a throwback to the days when C compilers had a single
namespace for all structure elements, not a readability aid. If you need
foo_ to know what type of structure you're futzing with, you need to name
your variables better.
Not
On Tue, 22 May 2001, Jean-Marc Saffroy wrote:
Hello,
I have the following question for VFS gurus here:
In the inode struct, an address_space (i_data) and a pointer to an
address_space (i_mapping) are defined, and it looks like i_mapping is
always a reference to the inode's i_data
On Tue, 22 May 2001, Oliver Xymoron wrote:
Not always. If the thing is used all over the tree, it'd better be
greppable. I hate the foo-de stuff - it's not localized and it's
impossible to grep for.
I'd like to say the compiler will happily find it for you, but the
kernel's mostly
1 - 100 of 1791 matches
Mail list logo
