Messages in this thread Patch in this message | | | From | "Doug Grove" <> | Subject | Re: linux-kernel-digest V1 #1322 | Date | Mon, 14 Aug 2000 20:43:17 -0500 |
| |
How do I get off this listserver? ----- Original Message ----- From: <owner-linux-kernel-digest@vger.rutgers.edu> To: <linux-kernel-digest@vger.rutgers.edu> Sent: Monday, August 14, 2000 6:47 AM Subject: linux-kernel-digest V1 #1322
> > linux-kernel-digest Monday, August 14 2000 Volume 01 : Number 1322 > > In this issue: > > Re: NTFS-like streams? > Re: [Sligtly Off-Topic] Status of Linux running on Athlon based boards? > Re: [patch-2.4.0-test7-pre3] forced umount support > 2.4.0-test7-pre3 doesn't boot > Re: NTFS-like streams? > Re: NTFS-like streams? > Re: 2.4.0-test7-pre3 doesn't boot > Re: Definitions > Re: pte_pagenr/MAP_NR deleted in pre6 > Re: 2.4.0-test{3,6} oopses on I2O init > Re: NTFS-like streams? > Re: Module mapping to mem/kmem? > Re: NTFS-like streams? > Re: NTFS-like streams? > Re: Definitions > Re: [CHECKER] null ptr checking > [PATCH] 2.4.0-test7-pre3 and rtnetlink oops > APIC error interrupt routine. > Re: NTFS-like streams? > Re: [patch] 2.4.0-pre6 StackGuard gcc makefile fix > Re: NTFS-like streams? > Re: [patch] lowlatency patch for 2.4, lowlatency-2.4.0-test6-B5 > Re: NTFS-like streams? > Re: Loading initrd over serial line > Re: socket->ops->connect() impossible in-kernel > Re: devfs / eth micro-problems > Re: Linux 2.2.17pre16 CPU detection wrong > linux/Documentation/sound/via82cxxx.txt is missing in 2.2.17-pre16 > Re: NTFS-like streams? > Re: NTFS-like streams? > Documentation Specialist Seeking Contract Work > Re: NTFS-like streams? > Re: NTFS-like streams? > Re: NTFS-like streams? > > See the end of the digest for information on subscribing to the linux-kernel > or linux-kernel-digest mailing lists. > > ---------------------------------------------------------------------- > > From: James Sutherland <jas88@cam.ac.uk> > Date: Mon, 14 Aug 2000 09:43:09 +0100 (BST) > Subject: Re: NTFS-like streams? > > On Sun, 13 Aug 2000, Horst von Brand wrote: > > > Alexander Viro <viro@math.psu.edu> said: > > > On Mon, 14 Aug 2000, James Sutherland wrote: > > > > > Sorry? I do rename("foo","bar"); Suddenly foo:splat becomes bar:splat. > > > > > Which of them should I drop? > > > > > > What has that got to do with short filenames? > > > > > Sigh... OK, I really need more coffee. Let me put it that way: this > > > behaviour (names migrating as the result of operation on different names) > > > has really nasty implications. On VFAT we had it due to short names. Your > > > proposal on NTFS promises the same sort of fun. Experience from dealing > > > with the shortname problems on VFAT makes me rather unhappy about your > > > proposal. > > > > The idea is that foo:splat is directory:file (with a funny, FS-specific > > separator) makes most sense. > > Except that it isn't a directory. Good start :-) > > > But this kind of crap obviously won't be reasonably mappable to honest > > filesystems, and much less mappable to other dishonest ones. > > Yup. It's HORRIBLE. Apart from anything else: If I copy one of these > "directories" to ext2 and back, how does NTFS "know" the "directory" it's > being handed is really supposed to be a file on NTFS, but a directory on > ext2? And how many sickbags will the users need when they see this? > > > I see Linus' point: If we want to support NTFS, and so on, we must do it > > right (i.e., preserving full semantics) as far as possible. As for Linux > > growing such warts on its own, I very much doubt it after this second (or > > is it third?) round of this flamewar. It just doesn't fit well with the > > general POSIX model, and where it fits it is just a funny kind of > > directory, which is absolutely pointless IMVHO. > > > > So, there are some points to clarify: > > > > - What are the exact kinds of these (to us alien) constructions that are > > around? Semantics, including size limitations, > > None. They're files. > > > atomicity or file-like properties are important here. > > File-like properties: > > 1. They are files. > 2. They look like files. > 3. They smell like files. > 4. They taste like files. > > The only distinction is that they share the [acm]time and permissions with > one or more other files of a similar name, under NTFS. > > > - For what use is the support intended? To be able to serve files from > > alien filesystems to machines expecting the same alien filesystem only? > > More than that: porting NT apps to Linux will need this support locally. > The NT apps will expect to be able to open these streams as > "filename:stream", without screwing with > pseudo-virtual-magic-directory-mount-point things. > > > - Is it enough to manage non-POSIX semantics on alien filesystems by > > specialized userland tools? > > No. If possible, the normal tools should work as expected. > > > How important is said manipulation? How important will it be? > > Not critical, but very desirable. > > > To what real use is this stuff put on the alien > > OSes? Is is important, or just a "cool" feature looking for (mis)use? > > (I'm assuming Linux will stay POSIX in its core, so native Linux > > applications for this is just a non-issue). > > I would doubt that: there are reasonable uses for it, and I can't see what > is "non-POSIX" about this feature. > > > - How many people think they will have a real-world use for such a feature? > > AFAIKS, the uses are either in some emulator for the alien OS (which will > > have to handle it in the alien way anyway, and is no issue to Linux), or > > in clones of alien tools that use this stuff, and they will have to pick > > the file appart on their own anyway (probably through a filesystem/alien > > OS specific library). > > s/clones/ports/. Having these features will make porting much easier. They > are also useful features in their own right. > > > AFAIKS, this is mostly a non-issue, as long as tar(1) and similar tools get > > a handle they can use to get/create the bytestream that constitutes the > > "structured" file in some way, > > Hang on - "structured" files?! Where on earth did that spring from? We're > talking about file-system file data attributes (i.e. files). > > > which can very well be different from filesystem to filesystem (and > > will have to be, you are trying to map non-POSIX to a sane POSIX > > approximation here in the first place). Or just give up, and give > > users NTFStools just like e2fstools to dump, restore, fsck, and > > whatever. We are doing so even for _native_ Linux filesystems! Please > > note that "Changing tar(1) is a three-liner with this kernel > > super-hack" just doesn't cut it: Portability from/to Linux has made it > > great, and there are just way too many such "three-liners" that would > > have to be designed, installed, tested, and then rammed down the > > throats of the respective maintainers, and kept up to date for the > > benefit of a tiny minority. > > My approach avoids the need for ANY changes to tar & co. Much saner. > > > Sure, to get it done in a sane way would be a very cool hack. I just doubt > > it is possible (too many different ideas of what precisely "structured > > files" are all about are floating around), > > Structured files are a completely different issue - probably a userspace > one, too. FS-level streams are kernel-side, and another matter entirely. > > > and if possible that it is at all worthwhile to do it in the kernel, > > and not by special tools for each case. > > I don't see the need for that sort of thing yet, but that's another issue > entirely. > > > James. > > > Please read the FAQ at http://www.tux.org/lkml/ > > ------------------------------ > > From: Martin Tessun <martin.tessun@class.de> > Date: Mon, 14 Aug 2000 10:17:56 +0200 > Subject: Re: [Sligtly Off-Topic] Status of Linux running on Athlon based boards? > > Hi, > > > Since my trustworthy, old computer (which is also part/time > > server for a little network that I have) is starting to have > > problems, I think that I'll buy another in the near future. > > > > Evaluating some of the alternatives, I see that an Athlon > > based system would be a good purchase. I did a little research > > and it seems that the best motherboards for such beasts would > > be the Asus K7V and the Abit KA7-100. These boards use the VIA > > KX133 chipset and feature UDMA/100 controllers, which > > according to André's site, Linux now supports. > > I have also running an Abit KA7 (not -100, because my system is somewhat > older ;) ). I experienced no problems so far. > > A few bits about my System: > > worf:~ # cat /proc/cpuinfo > processor : 0 > vendor_id : AuthenticAMD > cpu family : 6 > model : 2 > model name : AMD Athlon(tm) Processor > stepping : 1 > cpu MHz : 750.050957 > cache size : 512 KB > fdiv_bug : no > hlt_bug : no > sep_bug : no > f00f_bug : no > coma_bug : no > fpu : yes > fpu_exception : yes > cpuid level : 1 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca > cmov pat pse36 mmxext mmx fxsr 3dnowext 3dnow > bogomips : 1494.22 > > worf:~ # lspci > 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0391 (rev > 02) > 00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8391 > 00:07.0 ISA bridge: VIA Technologies, Inc.: Unknown device 0686 (rev 22) > 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev > 10) > 00:07.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10) > 00:07.3 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10) > 00:07.4 Host bridge: VIA Technologies, Inc.: Unknown device 3057 (rev > 30) > 00:0b.0 Ethernet controller: Davicom Semiconductor, Inc.: Unknown device > 9102 (rev 10) > 00:0d.0 Multimedia audio controller: Creative Labs SB Live! (rev 07) > 00:0d.1 Input device controller: Creative Labs SB Live! Daughterboard > (rev 07) > 00:11.0 SCSI storage controller: Symbios Logic Inc. (formerly NCR) > 53c895 (rev 01) > 01:00.0 VGA compatible controller: Nvidia Corporation: Unknown device > 0100 (rev 10) > worf:~ # cat /proc/interrupts > CPU0 > 0: 713593 XT-PIC timer > 1: 4522 XT-PIC keyboard > 2: 0 XT-PIC cascade > 5: 2561 XT-PIC EMU10K1 > 8: 2 XT-PIC rtc > 9: 0 XT-PIC acpi > 10: 35470 XT-PIC eth0 > 11: 63807 XT-PIC sym53c8xx > 12: 39508 XT-PIC PS/2 Mouse > 13: 1 XT-PIC fpu > NMI: 0 > ERR: 0 > worf:~ # uname -a > Linux worf 2.4.0-test6 #11 Sun Aug 13 22:43:59 CEST 2000 i686 unknown > worf:~ # > > I hope this is enough. No problems so far. The system runs very stable > under Linux, although it has some Problems under Windows (mainly > concerned to the soundcard and DirectX). > > HTH > Martin > > Please read the FAQ at http://www.tux.org/lkml/ > > ------------------------------ > > From: Tigran Aivazian <tigran@veritas.com> > Date: Mon, 14 Aug 2000 10:03:10 +0100 (BST) > Subject: Re: [patch-2.4.0-test7-pre3] forced umount support > > On Mon, 14 Aug 2000, Tigran Aivazian wrote: > > > There are no known problems with it so please report to me absolutely > > > anything suspicious you find. > > > > There is one known problem (Al Viro found it!) - I access files->fd > > without locking - this is a bug, fix to follow soon. > > > > Thanks to Alexander Viro for pointing this out. > > as promised, here is the fix but it is untested because test7-pre3 doesn't > boot on my machine (loops somewhere in the area flush_old_exec()) so I > need to debug this one first. This is a plain 2.4.0-test7-pre3 without any > patches. > > Regards, > Tigran > > diff -urN -X dontdiff linux/fs/Makefile badfs/fs/Makefile > - --- linux/fs/Makefile Thu Aug 10 06:51:11 2000 > +++ badfs/fs/Makefile Mon Aug 14 08:45:10 2000 > @@ -18,9 +18,9 @@ > ALL_SUB_DIRS := coda minix ext2 fat msdos vfat proc isofs nfs umsdos ntfs \ > hpfs sysv smbfs ncpfs ufs efs affs romfs autofs hfs lockd \ > nfsd nls devpts devfs adfs partitions qnx4 udf bfs cramfs \ > - - openpromfs autofs4 ramfs jffs > + openpromfs autofs4 ramfs jffs badfs > > - -SUB_DIRS := > +SUB_DIRS := badfs > > ifeq ($(CONFIG_QUOTA),y) > O_OBJS += dquot.o > diff -urN -X dontdiff linux/fs/badfs/Makefile badfs/fs/badfs/Makefile > - --- linux/fs/badfs/Makefile Thu Jan 1 01:00:00 1970 > +++ badfs/fs/badfs/Makefile Mon Aug 14 08:45:10 2000 > @@ -0,0 +1,9 @@ > +# > +# Makefile for badfs filesystem. > +# > + > +O_TARGET := badfs.o > +O_OBJS := inode.o > +M_OBJS := $(O_TARGET) > + > +include $(TOPDIR)/Rules.make > diff -urN -X dontdiff linux/fs/badfs/inode.c badfs/fs/badfs/inode.c > - --- linux/fs/badfs/inode.c Thu Jan 1 01:00:00 1970 > +++ badfs/fs/badfs/inode.c Mon Aug 14 09:00:06 2000 > @@ -0,0 +1,272 @@ > +/* > + * badfs - the Bad Filesystem > + * > + * Author - Tigran Aivazian <tigran@veritas.com> > + * > + * Thanks to: > + * Manfred Spraul <manfred@colorfullife.com>, for useful comments. > + * > + * This file is released under the GPL. > + * > + * The badfs filesystem is used by forced umount ('umount -f' command) > + * to move inodes that keep the filesystem being umounted busy to it. > + * > + * The entry point into this module is via quiesce_filesystem() called > + * from fs/super.c:do_umount() if MNT_FORCE is passed. > + */ > + > +#include <linux/module.h> > +#include <linux/init.h> > +#include <linux/sched.h> > +#include <linux/mm.h> > +#include <linux/file.h> > + > +#define BADFS_MAGIC 0xBADF0001 > + > +static struct super_block *badfs_read_super(struct super_block *,void *,int); > + > +#define FS_FLAGS_BADFS (FS_NOMOUNT | FS_SINGLE) > +static DECLARE_FSTYPE(badfs_fs_type,"badfs",badfs_read_super,FS_FLAGS_BADFS); > + > +static struct vfsmount *badfs_mnt; /* returned by kern_mount() */ > +static struct super_block *badfs_sb; /* badfs_mnt->mnt_sb */ > +static struct dentry *badfs_root; /* badfs_sb->s_root */ > + > +static int __init init_badfs_fs(void) > +{ > + int err = register_filesystem(&badfs_fs_type); > + > + if (!err) { > + badfs_mnt = kern_mount(&badfs_fs_type); > + if (IS_ERR(badfs_mnt)) { > + err = PTR_ERR(badfs_mnt); > + unregister_filesystem(&badfs_fs_type); > + } else { > + badfs_sb = badfs_mnt->mnt_sb; > + err = 0; > + } > + } > + return err; > +} > + > +module_init(init_badfs_fs); > + > +static struct inode *badfs_get_inode(struct super_block *sb, int mode) > +{ > + struct inode *inode = get_empty_inode(); > + > + if (inode) { > + make_bad_inode(inode); > + inode->i_sb = sb; > + inode->i_dev = sb->s_dev; > + inode->i_mode = mode; > + inode->i_nlink = 1; > + inode->i_size = 0; > + inode->i_blocks = 0; > + } > + return inode; > +} > + > +/* VFS ->read_super() method */ > +static struct super_block *badfs_read_super(struct super_block * sb, > + void * data, int silent) > +{ > + static struct super_operations badfs_ops = {}; > + struct inode * root = badfs_get_inode(sb, S_IFDIR|S_IRUSR|S_IWUSR); > + > + if (!root) > + return NULL; > + sb->s_blocksize = 1024; > + sb->s_blocksize_bits = 10; > + sb->s_magic = BADFS_MAGIC; > + sb->s_op = &badfs_ops; > + badfs_root = sb->s_root = d_alloc(NULL, > + &(const struct qstr){ "bad:", 5, 0}); > + if (!badfs_root) { > + iput(root); > + return NULL; > + } > + sb->s_root->d_sb = sb; > + sb->s_root->d_parent = sb->s_root; > + d_instantiate(sb->s_root, root); > + return sb; > +} > + > +static void disable_pwd(struct fs_struct *fs) > +{ > + struct inode *inode; > + struct dentry *dentry; > + > + inode = badfs_get_inode(badfs_sb, S_IFDIR|0755); > + if (!inode) { > + printk(KERN_ERR "disable_pwd(): can't allocate inode\n"); > + return; > + } > + dentry = d_alloc(badfs_root, &(const struct qstr){"dead_pwd", 8, 0}); > + if (!dentry) { > + iput(inode); > + printk(KERN_ERR "disable_pwd(): can't allocate dentry\n"); > + return; > + } > + d_instantiate(dentry, inode); > + dget(dentry); > + set_fs_pwd(fs, badfs_mnt, dentry); > +} > + > +static void disable_root(struct fs_struct *fs) > +{ > + struct inode *inode; > + struct dentry *dentry; > + > + inode = badfs_get_inode(badfs_sb, S_IFDIR|0755); > + if (!inode) { > + printk(KERN_ERR "disable_root(): can't allocate inode\n"); > + return; > + } > + dentry = d_alloc(badfs_root, &(const struct qstr){"dead_root", 9, 0}); > + if (!dentry) { > + iput(inode); > + printk(KERN_ERR "disable_root(): can't allocate dentry\n"); > + return; > + } > + d_instantiate(dentry, inode); > + dget(dentry); > + set_fs_root(fs, badfs_mnt, dentry); > +} > + > +/* called from do_umount() if MNT_FORCE is specified */ > +void quiesce_filesystem(struct vfsmount *mnt) > +{ > + struct task_struct *p; > + struct file *file; > + struct inode *inode; > + > + /* we do three passes through the task list, examining: > + * 1. p->fs{->pwd,root} that can keep this mnt busy > + * 2. p->files, i.e. open files (we do_close them) > + * 3. p->mm, i.e. mmaped files (we simply do_munmap them) > + * There is no guarantee that by the time we restart the loop > + * the amount of work to do in the loop has not increased. > + */ > +repeat1: > + read_lock(&tasklist_lock); > + for_each_task(p) { > + struct fs_struct *fs; > + > + /* get a reference to p->fs */ > + task_lock(p); > + fs = p->fs; > + if (!fs) { > + task_unlock(p); > + continue; > + } else > + atomic_inc(&fs->count); > + task_unlock(p); > + > + if (fs->pwdmnt == mnt) { > + read_unlock(&tasklist_lock); > + disable_pwd(fs); /* may sleep */ > + put_fs_struct(fs); > + goto repeat1; > + } > + if (fs->rootmnt == mnt) { > + read_unlock(&tasklist_lock); > + disable_root(fs); /* may sleep */ > + put_fs_struct(fs); > + goto repeat1; > + } > + put_fs_struct(fs); > + } > + read_unlock(&tasklist_lock); > + > +repeat2: > + read_lock(&tasklist_lock); > + for_each_task(p) { > + unsigned int fd, j = 0; > + struct files_struct *files; > + > + /* get a reference to p->files */ > + task_lock(p); > + files = p->files; > + if (!files) { > + task_unlock(p); > + continue; > + } else { > + atomic_inc(&files->count); > + write_lock(&files->file_lock); > + } > + task_unlock(p); > + > + /* check if this process has open files here */ > + while (1) { > + unsigned long set; > + > + fd = j * __NFDBITS; > + if (fd >= files->max_fdset || fd >= files->max_fds) > + break; > + set = files->open_fds->fds_bits[j++]; > + while (set) { > + if (set & 1) { > + file = files->fd[fd]; > + inode = file->f_dentry->d_inode; > + if (inode && (file->f_vfsmnt==mnt)) { > + files->fd[fd] = NULL; > + FD_CLR(fd, files->close_on_exec); > + __put_unused_fd(files, fd); > + write_unlock(&files->file_lock); > + read_unlock(&tasklist_lock); > + put_files_struct(files); > + filp_close(file, files); > + goto repeat2; > + } > + } > + fd++; > + set >>= 1; > + } > + } > + write_unlock(&files->file_lock); > + put_files_struct(files); > + } > + read_unlock(&tasklist_lock); > + > +repeat3: > + read_lock(&tasklist_lock); > + for_each_task(p) { > + struct mm_struct *mm; > + struct vm_area_struct *vma; > + > + /* get a reference to p->mm */ > + task_lock(p); > + mm = p->mm; > + if (!mm) { > + task_unlock(p); > + continue; > + } else > + atomic_inc(&mm->mm_users); > + task_unlock(p); > + > + /* check for mmap'd files and unmap them */ > + vmlist_modify_lock(mm); > + for (vma = mm->mmap; vma; vma=vma->vm_next) { > + file = vma->vm_file; > + if (!file) > + continue; > + inode = file->f_dentry->d_inode; > + if (!inode || !inode->i_sb) > + continue; > + if (file->f_vfsmnt == mnt) { > + vmlist_modify_unlock(mm); > + read_unlock(&tasklist_lock); > + down(&mm->mmap_sem); > + do_munmap(mm, vma->vm_start, > + vma->vm_end - vma->vm_start); > + up(&mm->mmap_sem); > + mmput(mm); > + goto repeat3; > + } > + } > + vmlist_modify_unlock(mm); > + mmput(mm); > + } > + read_unlock(&tasklist_lock); > +} > diff -urN -X dontdiff linux/fs/super.c badfs/fs/super.c > - --- linux/fs/super.c Mon Aug 14 08:10:58 2000 > +++ badfs/fs/super.c Mon Aug 14 08:45:10 2000 > @@ -1033,6 +1033,9 @@ > return retval; > } > > + if (flags&MNT_FORCE) > + quiesce_filesystem(mnt); > + > spin_lock(&dcache_lock); > if (atomic_read(&mnt->mnt_count) > 2) { > spin_unlock(&dcache_lock); > diff -urN -X dontdiff linux/include/linux/fs.h badfs/include/linux/fs.h > - --- linux/include/linux/fs.h Mon Aug 14 08:10:58 2000 > +++ badfs/include/linux/fs.h Mon Aug 14 08:52:15 2000 > @@ -1191,6 +1191,8 @@ > extern kdev_t ROOT_DEV; > extern char root_device_name[]; > > +/* fs/badfs/inode.c - used by forced umount */ > +extern void quiesce_filesystem(struct vfsmount *); > > extern void show_buffers(void); > extern void mount_root(void); > > > Please read the FAQ at http://www.tux.org/lkml/ > > ------------------------------ > > From: Tigran Aivazian <tigran@veritas.com> > Date: Mon, 14 Aug 2000 10:05:52 +0100 (BST) > Subject: 2.4.0-test7-pre3 doesn't boot > > Hi guys, > > Just a quick note saying that the last thing I see is "Freeing unused > memory: 240k" and then it appears to loop entering and leaving > flush_old_exec() and the only task (apart from the usual kernel > threads) is the init, which is running, R). > > I will _slowly_ investigate this (instruction at a time) of if anyone has > fast ideas - let me know. > > Regards, > Tigran > > > Please read the FAQ at http://www.tux.org/lkml/ > > ------------------------------ > > From: James Sutherland <jas88@cam.ac.uk> > Date: Mon, 14 Aug 2000 10:01:33 +0100 (BST) > Subject: Re: NTFS-like streams? > > On 14 Aug 2000 wingel@t1.ctrl-c.liu.se wrote: > > > [replying to my self *sigh*] > > I wrote: > > >Files with alternate streams look exactly like normal files except > > >that they also have a S_IFCOMPLEX flag and that one can use them as > > >directories. When accessing such a file as a directory, it should > > >act as a separate filesystem of its own, so that renames and links > > >work inside this filesystem, but not outside it: > > > > This introduces one new thing which is really incompatible with > > POSIX filesystems, a file that can also act as a directory. > > That's absolutely horrible. > > > What is the basic reason why this directory can't live in a special > > directory called ".fork"? So instead of doing "cd file-with-forks" > > one does "cd .fork/file-with-forks"? > > That's also horrible. > > BTW: What do you do if there's a real directory called ".fork"? Or a file? > > You also still have the original problem of naming the forks! > > If I create "foo" and "bar", both with a fork called "splat", what tree do > I get? This one: > > foo > bar > .fork/foo:splat > .fork/bar:splat > > (i.e. my idea, but with all the files partially duplicated under magically > created special directories)? This is truly horrible. > > > That would work on ext2, NFS or any POSIX like filesystem. > > It might possibly work, but it would leave a mess on the keyboard. Don't > do it. > > > The disadvantage is that there will be a magic directory called > > .fork (with the same permissions as the parent directory I suppose) > > which can't be renamed or deleted. The subdirectories inside > > the .fork-directory would have the same permissions as the > > corresponding file and would have the same limitations as mounted > > filesystems, no hardlinks outside of the directory. And if one > > deletes or renames the parent, the .fork directory follows. > > It's a horrible mess, and it solves precisely NOTHING - the same problem > remains! > > > James. > > > Please read the FAQ at http://www.tux.org/lkml/ > > ------------------------------ > > From: tdanis@canal-plus.fr > Date: Mon, 14 Aug 2000 11:19:21 +0200 > Subject: Re: NTFS-like streams? > > On Sat, Aug 12, 2000 at 01:49:34PM -0700, torvalds@transmeta.com wrote: > > In article <Pine.LNX.4.21.0008121047190.14835-100000@duckman.distro.conectiva>, > > Rik van Riel <riel@conectiva.com.br> wrote: > > >On Sat, 12 Aug 2000, Michael Rothwell wrote: > > >> Rik van Riel wrote: > > >> > > >> > So what we want are directories, and not file streams? > > >> > Oh wait, we already have those... > > >> > > >> Not really. Directories aren't the same thing, > > >> and don't serve the same purpose. They're _similar_, > > >> but not identical. > > > > > >So what is The Big Difference(tm) that make file streams > > >so much better than directories and so much different? > > > > I'll talk really slowly. > > > > HFS has resource forks. They are not directories. Linux cannot handle > > them well. > > > > I'm all for handling HFS resource forks. It's called "interoperability". > > > > [...] > > Real "interoperability" for me would mean network EA aware > filesystems. Since we are NFS [auto]mounting FrameMaker, > StarOffice & Co from a server, EAs would be lost even if > the server had an EA aware local filesystem. > > Maybe could it be a useful extension to the forecoming > NfsV4 implementation... > > > > > Linus > > > - -- > Thierry > > Please read the FAQ at http://www.tux.org/lkml/ > > ------------------------------ > > From: "David S. Miller" <davem@redhat.com> > Date: Mon, 14 Aug 2000 02:13:05 -0700 > Subject: Re: 2.4.0-test7-pre3 doesn't boot > > A fix was posted for this yesterday (several times in fact ;-) > > - --- ../vanilla/linux/fs/exec.c Sat Aug 12 22:52:10 2000 > +++ fs/exec.c Sun Aug 13 08:50:39 2000 > @@ -481,8 +481,10 @@ > if (i >= files->max_fds || i >= files->max_fdset) > break; > set = files->close_on_exec->fds_bits[j]; > - - if (!set) > + if (!set) { > + j++; > continue; > + } > files->close_on_exec->fds_bits[j] = 0; > j++; > write_unlock(&files->file_lock); > > Please read the FAQ at http://www.tux.org/lkml/ > > ------------------------------ > > From: Horst von Brand <vonbrand@sleipnir.valparaiso.cl> > Date: Sun, 13 Aug 2000 23:59:17 -0400 > Subject: Re: Definitions > > Chris Mason <mason@suse.com> said: > > [...] > > > The current journal code limits the number of async transactions to 5, so > > any given user should not be able to pin more than ~20MB of ram per FS > > (each transaction is a max of 1024, 4k blocks). The admin can change > > this by setting JOURNAL_NUM_BITMAPS to any number >= 2 (controls the > > number of async transactions), and changing JOURNAL_MAX_BATCH to any > > number larger than 256 (one way to control max blocks per transaction, it > > could be set smaller, but that would be slow). > > Great! So the Evil Bastard can only eat up 60Mb of RAM (/tmp, /var, /home > have pieces that are writable to a user). He just needs a buddy to kill > this machine (128Mb RAM) very much dead then. Now I can sleep well. Or > perhaps have half a dozen users doing nothing in particular, and the > machine is OOM. > > 20Mb RAM for a filesystem per user is _ridiculous_, AFAIAC. Most users > around here have much less for a quota! > - -- > Horst von Brand vonbrand@sleipnir.valparaiso.cl > Casilla 9G, Vin~a del Mar, Chile +56 32 672616 > > > Please read the FAQ at http://www.tux.org/lkml/ > > ------------------------------ > > From: Roman Zippel <roman@augan.com> > Date: Mon, 14 Aug 2000 11:29:22 +0200 > Subject: Re: pte_pagenr/MAP_NR deleted in pre6 > > Hi, > > > And even if it doesn't help m68k, it definitely will help mips64, ia64 > > and ARM (from what I am understanding from Russell). So, unless it is > > _breaking_ m68k, I would rather see the patch go in ... > > No, it doesn't :) and I think I can start thinking to make it usable > under m68k. > > bye, Roman > > Please read the FAQ at http://www.tux.org/lkml/ > > ------------------------------ > > From: Christian Bricart <Christian@bricart.de> > Date: Mon, 14 Aug 2000 11:27:36 +0200 > Subject: Re: 2.4.0-test{3,6} oopses on I2O init > > On Sun, Aug 13, 2000 at 11:56:12PM +0100, Alan Cox wrote: > > > I tried to run Kernel 2.4.0-test6 on a HP LH4 today. After I received > > > an Oops, I tried 0.2.0-pre3 on the same machine. (have to stick > > > to -pre{3,6} for ReiserFS issues) > > > > Compile a current standard linus kernel without reiserfs and repeat the > > experiment (its dying before the fs is loaded so you shouldnt have a problem > > here) > > Ok .. tried plain 2.4.0-test6 with the three line patch in > drivers/pci/setup-res.c > > same oops ... > > Christian > > - -- > Things that make you go "Hmmm": > "If a train station is where the train stops, what is a workstation?" > > > Please read the FAQ at http://www.tux.org/lkml/ > > ------------------------------ > > From: David Woodhouse <dwmw2@redhat.com> > Date: Mon, 14 Aug 2000 10:30:51 +0100 > Subject: Re: NTFS-like streams? > > vickery@ntcv.cs.qc.edu said: > > NTFS allows you to create multiple "streams" within a file. "echo > > hello > x:y" creates a zero-byte file named x with a "stream" named y > > containing hello. > > We have something very similar under Linux. > > We call them 'directories'. > > "mkdir x ; echo hello > x/y" creates a 'directory' named x with a 'file' > named y containing hello. > > > - -- > dwmw2 > > > > Please read the FAQ at http://www.tux.org/lkml/ > > ------------------------------ > > From: Jamie Lokier <lk@tantalophile.demon.co.uk> > Date: Mon, 14 Aug 2000 11:41:59 +0200 > Subject: Re: Module mapping to mem/kmem? > > Dave Cecil wrote: > > I want to display the value of a variable in my loadable module, but of > > course gdb vmlinux /proc/kcore can't do that. > > > > Is there another, better technique, maybe using kmem? > > Feel free to change /proc/kcore so it includes loaded modules. While > there, include information about the modules in the appropriate format, > and GDB will automatically load the module symbols. (Basically, make it > look like the core file refers to shared libraries). > > More effort perhaps, but it would be much better technique IMHO :-) > > - -- Jamie > > Please read the FAQ at http://www.tux.org/lkml/ > > ------------------------------ > > From: Christer Weinigel <wingel@hog.ctrl-c.liu.se> > Date: 14 Aug 2000 09:51:26 -0000 > Subject: Re: NTFS-like streams? > > jas88@cam.ac.uk wrote: > > > This introduces one new thing which is really incompatible with > > > POSIX filesystems, a file that can also act as a directory. > > > > That's absolutely horrible. > > > > > What is the basic reason why this directory can't live in a special > > > directory called ".fork"? So instead of doing "cd file-with-forks" > > > one does "cd .fork/file-with-forks"? > > > > That's also horrible. > > It might be horrible, but how else are you going to solve it? As > Linus has said, NTFS is not POSIX compatible anyway, but it has to be > supported somehow. > > > BTW: What do you do if there's a real directory called ".fork"? Or a > > file? > > Tough luck, on NTFS file systems the name ".fork" is reserved. > > > You also still have the original problem of naming the forks! > > > > If I create "foo" and "bar", both with a fork called "splat", what tree do > > I get? This one: > > > > foo > > bar > > .fork/foo:splat > > .fork/bar:splat > > Almost, with / instead of : as the separator. > > bash$ ls -R .fork > .fork: > total 8 > drwxrwxr-x 3 wingel wingel 4096 Aug 14 11:48 foo > drwxrwxr-x 3 wingel wingel 4096 Aug 14 11:49 bar > > ./fork/foo: > total 160 > - -rw-rw-r-- 1 wingel wingel 154270 Aug 11 15:31 splat > > ./fork/bar: > total 160 > - -rw-rw-r-- 1 wingel wingel 154270 Aug 11 15:31 splat > > > > That would work on ext2, NFS or any POSIX like filesystem. > > > > It might possibly work, but it would leave a mess on the keyboard. Don't
> > do it. > > It's how AppleShare has been done with Netatalk for a long time. > > /Christer > > > - -- > "Just how much can I get away with and still go to heaven?" > > Please read the FAQ at http://www.tux.org/lkml/ > > ------------------------------ > > From: Pavel Machek <pavel@suse.cz> > Date: Mon, 14 Aug 2000 11:56:41 +0200 > Subject: Re: NTFS-like streams? > > Hi! > > > > > and then access the "Icon" resource in it by just doing > > > > > > > > xv ~/myfile/Icon > > > > > > Sorry, this is not going to work. I played with this with podfuk, and > > > xv will probably stat myfile (just for fun), notice it is regular > > > file, and refuse to try to open myfile/Icon. > > > > > > What you however can do is xv ~/myfile#utar/Icon. This actually works > > > for me. > > > > I don't think this is a strong argument. Any program that "knows" that it > > is handling a POSIX filesystem and simply does part of the work itself is > > always going to break on extensions. That's just unavoidable. Adding the > > magic string at the end makes "xv" happy, but might easily make something > > else that assumes POSIX behaviour unhappy instead (ie somebody else does > > 'stat("myfile#utar")' and is unhappy because it doesn't exist). > > But stat myfile#utar _does_ exist, and is a directory. Program could > get confused because myfile#utar does not appear on directory listing, > that's about it. I added magicall files that do not appear on > directory listings, but are there for every other operation. This sees > to have done very little breakage. > > > [ Put another way: I suspect that we won't support resource forks natively > > for another few years, and HFS etc will have their own specialized > > stuff. I don't care all that much. But at the same time I do believe > > that eventually we'll probably have to handle it. And at _that_ point I > > care about the fact that our internal design has to be robust. It > > doesn't have to make everybody happy, but it has to be clean both > > conceptually and from a pure implementation standpoint. I don't want a > > "hack that works". ] > > This is not hack. Imagine file that is both tarred and gzipped. Now, I > can look at its uncompressed but still tarred version: > > cat file.tgz#ugz > > or I can look at it as a directory > > ls file.tgz#utar. > > Okay, this is not what you asked for (resource forks), but I believe > it is even more usefull. > > Pavel > - -- > The best software in life is free (not shareware)! Pavel > GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+ > > Please read the FAQ at http://www.tux.org/lkml/ > > ------------------------------ > > From: "Andi Kleen" <ak@suse.de> > Date: Mon, 14 Aug 2000 12:01:08 +0200 > Subject: Re: Definitions > > On Sun, Aug 13, 2000 at 11:59:17PM -0400, Horst von Brand wrote: > > Great! So the Evil Bastard can only eat up 60Mb of RAM (/tmp, /var, /home > > have pieces that are writable to a user). He just needs a buddy to kill > > this machine (128Mb RAM) very much dead then. Now I can sleep well. Or > > perhaps have half a dozen users doing nothing in particular, and the > > machine is OOM. > > > > 20Mb RAM for a filesystem per user is _ridiculous_, AFAIAC. Most users > > around here have much less for a quota! > > First the limit is per file system, not per file system per user. > > Better forbid the users mmap and TCP/unix sockets then, because they can > easily pin more memory for their socket buffers or page tables (similar to > a lot of other subsystems) As long as there is no bean counter every user > can relatively easy tie up arbitary amounts of memory in Linux. Alternatively > you have to set their process/fd descriptors so low to make the machine > unusable for the user: > > e.g. 64K socket buffer per fd, you want to limit it to 5MB max/user > 5MB / 64K = 80 sockets. So you give them 10 processes with 8 file descriptors > each or 8 processes with 10 file descriptors? How many of the programs > your users use will still run with such low limits? > > The only more or less reliable way currently to prevent local DoS by users > is to separate them in UML virtual machines. > > - -Andi > > Please read the FAQ at http://www.tux.org/lkml/ > > ------------------------------ > > From: almesber@lrc.di.epfl.ch > Date: Mon, 14 Aug 2000 12:03:19 +0200 > Subject: Re: [CHECKER] null ptr checking > > Wallace Huang wrote: > > I'm Wallace, another member of Dawson's group, and I've been working on a > > checker that make sure folks check return values from allocation functions > > for NULL before using. > > Very good, thanks ! But it seems that your checker doesn't know about > dev_kfree_skb or kfree_skb. Also, it might be good to have a sorted > table of content (i.e. each file listed only once) at the beginning > of the posting - otherwise, it's quite hard to see if there's anything > one feels responsible for. > > I saw that in a later posting, you switched to tar.gz. I think an > easily readable ASCII version is more useful. Otherwise, only people > who already expect problems will actually look at it ... > > - - Werner > > - -- > _________________________________________________________________________ > / Werner Almesberger, ICA, EPFL, CH werner.almesberger@ica.epfl.ch / > /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/ > > Please read the FAQ at http://www.tux.org/lkml/ > > ------------------------------ > > From: Petr Vandrovec <vandrove@vc.cvut.cz> > Date: Mon, 14 Aug 2000 12:11:57 +0200 > Subject: [PATCH] 2.4.0-test7-pre3 and rtnetlink oops > > Hi Linus, > maybe you already received patch for this, but there are two problems with > net/socket.c: > > (1) use 'inode' before verifying for NULL > (2) registering sock_fs_type after rtnetlink_init; rtnetlink_init needs > sock_alloc; sock_alloc needs sock_mnt != NULL ... > > Thanks, > Petr Vandrovec > vandrove@vc.cvut.cz > > > > diff -urdN linux/net/socket.c linux/net/socket.c > - --- linux/net/socket.c Mon Aug 14 08:39:20 2000 > +++ linux/net/socket.c Mon Aug 14 10:00:50 2000 > @@ -440,10 +440,11 @@ > struct socket * sock; > > inode = get_empty_inode(); > - - inode->i_sb = sock_mnt->mnt_sb; > + > if (!inode) > return NULL; > > + inode->i_sb = sock_mnt->mnt_sb; > sock = socki_lookup(inode); > > inode->i_mode = S_IFSOCK|S_IRWXUGO; > @@ -1716,6 +1717,9 @@ > * The netlink device handler may be needed early. > */ > > + register_filesystem(&sock_fs_type); > + sock_mnt = kern_mount(&sock_fs_type); > + > #ifdef CONFIG_RTNETLINK > rtnetlink_init(); > #endif > @@ -1725,8 +1729,6 @@ > #ifdef CONFIG_NETFILTER > netfilter_init(); > #endif > - - register_filesystem(&sock_fs_type); > - - sock_mnt = kern_mount(&sock_fs_type); > } > > int socket_get_info(char *buffer, char **start, off_t offset, int length) > > Please read the FAQ at http://www.tux.org/lkml/ > > ------------------------------ > > From: R.E.Wolff@bitwizard.nl (Rogier Wolff) > Date: Mon, 14 Aug 2000 12:27:43 +0200 (MEST) > Subject: APIC error interrupt routine. > > Hi Linus, > > In the "APIC error interrupt" routine, some funny things happen: First > a spinlock is taken. Next some elaborate multiline prints are done, > reporting the "problem". Then the chip is "tickled" into being ready > for the next interrupt. Then the spinlock is unlocked. > > If I'm not mistaken, the chip could interrupt us after being tickled > to be ready for the next interrupt. Now, this 'error interrupt' > normally never happens, so the chances of this happening AGAIN before > the printk's finish should be minimal, right? No. > > In fact, the ABIT BP6 board is a bit shabby. It has a few problems. > Besides some versions having power supply issues, the APICs seem to > have transmission errors between them. When this happens, the APIC > ends up interrupting us a few times in quick succession, as probably > it's out of sync with its partner. > > So, one of the things that I think are happening with the lockups on > BP6's is that when the spinlock is still taken, the apic interrupts us > again and that's one dead CPU spinning for a lock that it holds > itself. The other CPU probably will start spinning for this same > spinlock within a few seconds, so to most people this will look like a > complete lockup. > > If I'm not mistaken, the spinlock should've been an "spinlock_irqsave" > in the first place, right? > > Anyway, I think it's safest to remove the spinlock alltogether, as > long as we ack the APIC at the latest possible moment. I also think > that it's safe to just postpone the "time consuming" printk to just > after the ack to the APIC. Worst case, we'll see a quick succession of > APIC irq's and the printk's may be messed up. So? > > What do you think about the attached patch? > > Eric Andreychek reported that he managed to get a full week of uptime > with this patch installed when before he'd get lockups within a > day. (After reporting this his machine started locking up a few times > in an hour to prove him wrong... :-( ). Anyway, I think that this is just > one of the issues with the board, which makes it > > Oh, typical output of the "new" function is: > > Aug 10 20:43:03 Paradise-Lost kernel: APIC error: 00(02) > Aug 10 21:04:48 Paradise-Lost kernel: APIC error: 02(02) > Aug 10 21:14:20 Paradise-Lost kernel: APIC error: 00(08) > Aug 10 21:23:47 Paradise-Lost kernel: APIC error: 08(08) > Aug 10 21:34:24 Paradise-Lost kernel: APIC error: 08(08) > Aug 10 21:47:06 Paradise-Lost kernel: APIC error: 02(04) > Aug 10 22:10:23 Paradise-Lost kernel: APIC error: 04(02) > Aug 10 22:12:02 Paradise-Lost kernel: APIC error: 08(04) > Aug 10 22:12:02 Paradise-Lost kernel: APIC error: 02(08) > Aug 10 22:29:32 Paradise-Lost kernel: APIC error: 08(02) > Aug 10 22:37:38 Paradise-Lost kernel: APIC error: 04(04) > Aug 10 22:37:38 Paradise-Lost kernel: APIC error: 02(08) > Aug 10 23:08:39 Paradise-Lost kernel: APIC error: 08(02) > > which means that indeed new bits seem to be coming on in the ESR > register during the course of this routine running. Shouldn't it be > much more common to see a "0" after the first try? Anyway please > correct me if my understanding of the APIC and this code is wrong... > > Roger. > > - ---------------------------------------------------------------------- > > - --- linux-2.4.0-test6-pre1.clean/arch/i386/kernel/apic.c Sat Aug 12 10:42:52 2000 > +++ linux-2.4.0-test6-pre1.fs50/arch/i386/kernel/apic.c Sat Aug 12 10:43:11 2000 > @@ -682,46 +709,28 @@ > * This interrupt should never happen with our APIC/SMP architecture > */ > > - -static spinlock_t err_lock = SPIN_LOCK_UNLOCKED; > - - > asmlinkage void smp_error_interrupt(void) > { > - - unsigned long v; > - - > - - spin_lock(&err_lock); > + unsigned long v, v1; > > + /* First tickle the hardware, only then report what went on. -- REW */ > v = apic_read(APIC_ESR); > - - printk(KERN_INFO "APIC error interrupt on CPU#%d, should never happen.\n", > - - smp_processor_id()); > - - printk(KERN_INFO "... APIC ESR0: %08lx\n", v); > - - > apic_write(APIC_ESR, 0); > - - v |= apic_read(APIC_ESR); > - - printk(KERN_INFO "... APIC ESR1: %08lx\n", v); > - - /* > - - * Be a bit more verbose. (multiple bits can be set) > - - */ > - - if (v & 0x01) > - - printk(KERN_INFO "... bit 0: APIC Send CS Error (hw problem).\n"); > - - if (v & 0x02) > - - printk(KERN_INFO "... bit 1: APIC Receive CS Error (hw problem).\n"); > - - if (v & 0x04) > - - printk(KERN_INFO "... bit 2: APIC Send Accept Error.\n"); > - - if (v & 0x08) > - - printk(KERN_INFO "... bit 3: APIC Receive Accept Error.\n"); > - - if (v & 0x10) > - - printk(KERN_INFO "... bit 4: Reserved!.\n"); > - - if (v & 0x20) > - - printk(KERN_INFO "... bit 5: Send Illegal Vector (kernel bug).\n"); > - - if (v & 0x40) > - - printk(KERN_INFO "... bit 6: Received Illegal Vector.\n"); > - - if (v & 0x80) > - - printk(KERN_INFO "... bit 7: Illegal Register Address.\n"); > - - > + v1 = apic_read(APIC_ESR); > ack_APIC_irq(); > - - > irq_err_count++; > > - - spin_unlock(&err_lock); > + /* Here is what the APIC error bits mean: > + 0: Send CS error > + 1: Receive CS error > + 2: Send accept error > + 3: Receive accept error > + 4: Reserved > + 5: Send illegal vector > + 6: Received illegal vector > + 7: Illegal register address > + */ > + printk (KERN_ERR "APIC error on CPU%d: %02x(%02x)\n", > + smp_processor_id(), v , v1); > } > > > > - -- > ** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 ** > *-- BitWizard writes Linux device drivers for any device you may have! --* > * Common sense is the collection of * > ****** prejudices acquired by age eighteen. -- Albert Einstein ******** > > Please read the FAQ at http://www.tux.org/lkml/ > > ------------------------------ > > From: David Woodhouse <dwmw2@redhat.com> > Date: Mon, 14 Aug 2000 11:37:07 +0100 > Subject: Re: NTFS-like streams? > > torvalds@transmeta.com said: > > But /bin/cp cannot do the same, at least not without teaching it to > > do the same thing as for a recursive directory copy (which a regular > > UNIX cp wouldn't even try to do on a regular file). But the recursive > > directory copy approach should work. > > Actually, a copyfile() system call would be able to do this transparently¹. > > This is one of the things I like about SMB - if you want to copy a 400MB file > from one place on the server to the another, you don't need to actually > transfer all its data over the wire. > > - -- > dwmw2 > > ¹ Not that I think it _should_, mind you. It doesn't help tar(1). > > > > > Please read the FAQ at http://www.tux.org/lkml/ > > ------------------------------ > > From: David Woodhouse <dwmw2@redhat.com> > Date: Mon, 14 Aug 2000 11:42:42 +0100 > Subject: Re: [patch] 2.4.0-pre6 StackGuard gcc makefile fix > > mec@shout.net said: > > In the top Makefile, $(CC) isn't usable until after the to Makefile > > includes arch/$(ARCH)/Makefile. This is because the arch Makefile can > > change the value of $(CROSS_COMPILE), which affects the value of > > $(CC). > > Under what circumstances is it valid for the arch Makefile to override the > setting of CROSS_COMPILE which the user has explicitly set in the top-level > Makefile? > > I thought it was only m68k which did this, and that it had since been fixed. > > - -- > dwmw2 > > > > Please read the FAQ at http://www.tux.org/lkml/ > > ------------------------------ > > From: Marc Lehmann <pcg@goof.com> > Date: Mon, 14 Aug 2000 12:43:47 +0200 > Subject: Re: NTFS-like streams? > > Just FYI on what other unices might do: HP-UX has "context dependent > files" (mainly for their clustered environment). On our veritable HP-UX > 9.05 box, I can do this: > > islhp7 #~# mkdir cfile > islhp7 #~# chmod +H cfile > islhp7 #~# ls cfile > cfile not found > islhp7 #~# cd cfile+ > islhp7 #/cfile+# echo hi >default > islhp7 #/cfile+# cd > islhp7 #~# cat cfile > hi > islhp7 #~# ls -ld c* > - -rw------- 1 root root 3 Aug 14 12:41 cfile > islhp7 #~# ls -ld cfile+ > drws------ 2 root root 1024 Aug 14 12:42 cfile+/ > > This is used to have different file contents for different nodes of a > cluster, breaks tar and a lot of other tools and is generally considered a > broken and useless feature ;) > > (btw, you can do it as normal user as well) > > - -- > -----==- | > ----==-- _ | > ---==---(_)__ __ ____ __ Marc Lehmann +-- > --==---/ / _ \/ // /\ \/ / pcg@opengroup.org |e| > -=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ > The choice of a GNU generation | > | > > Please read the FAQ at http://www.tux.org/lkml/ > > ------------------------------ > > From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr> > Date: Mon, 14 Aug 2000 12:24:45 +0200 (CEST) > Subject: Re: [patch] lowlatency patch for 2.4, lowlatency-2.4.0-test6-B5 > > On Fri, 4 Aug 2000, Rogier Wolff wrote: > > > Andrew Morton wrote: > > > - There's some device driver module which takes ~100 millisecs when it's > > > loaded (Benno has details). Leave it alone - we can't and shouldn't audit all > > > the device driver initialisation code. > > > > I haven't checked this, but I bet there are a few drivers that I've > > written that are a lot worse in this respect. I hope that this isn't a > > real problem for anyone? Don't use modules if it bothers you, or load > > the modules at boot, and make sure they don't unload. > > > > Also the NCR53C8XX driver probably hangs the machine for 2 full > > seconds during startup. > > Ah? > > Given default value for settle_time (2 seconds), it doesn't, but relies on > a kernel timer and local queuing for commands. The driver just doesn't > want to trigger time-outs from upper layer at start-up. Note that the > driver also takes care of lowering the current settle delay if a command > that may time out is queued during this settle delay. As a result, the > synchronous delay for settle time > 2 seconds at startup can probably be > removed, but this will require some testings. > > Obviously, the driver uses a couple of milli-seconds of synchronous small > delays to ensure that the hardware does initialize correctly. > > Gerard. > > PS1: the above applies to both ncr53c8xx and sym53c8xx drivers. > PS2: use statically linked drivers when possible. I consider statically > linked drivers to be a great feature? ;-) > > > Please read the FAQ at http://www.tux.org/lkml/ > > ------------------------------ > > From: James Sutherland <jas88@cam.ac.uk> > Date: Mon, 14 Aug 2000 11:51:25 +0100 (BST) > Subject: Re: NTFS-like streams? > > On 14 Aug 2000, Christer Weinigel wrote: > > > > That's also horrible. > > > > It might be horrible, but how else are you going to solve it? As > > Linus has said, NTFS is not POSIX compatible anyway, but it has to be > > supported somehow. > > Solve it the way I have already explained. NT is POSIX compliant, and uses > this implementation... > > > > BTW: What do you do if there's a real directory called ".fork"? Or a > > > file? > > > > Tough luck, on NTFS file systems the name ".fork" is reserved. > > Says who? It's not your file system. You just want the drivers to break on > perfectly legal NTFS partitions? > > > > You also still have the original problem of naming the forks! > > > > > > If I create "foo" and "bar", both with a fork called "splat", what tree do > > > I get? This one: > > > > > > foo > > > bar > > > .fork/foo:splat > > > .fork/bar:splat > > > > Almost, with / instead of : as the separator. > > Oh dear. We're back to the stupid pseudo-magic-directory-thing shit again. > > (snip vomit) > > > > > That would work on ext2, NFS or any POSIX like filesystem. > > > > > > It might possibly work, but it would leave a mess on the keyboard. Don't > > > do it. > > > > It's how AppleShare has been done with Netatalk for a long time. > > Making mistakes is normal. Repeating them should be avoided. > > > James. > > > Please read the FAQ at http://www.tux.org/lkml/ > > ------------------------------ > > From: almesber@lrc.di.epfl.ch > Date: Mon, 14 Aug 2000 13:06:41 +0200 > Subject: Re: Loading initrd over serial line > > Pavel Machek wrote: > > This patch should load initrd over serial line. > > Arrrghhh!!! > > Please, consider the following approach instead: > - add sufficient instrumentation to your architecture and boot loader > to load some initrd with your kernel > - make an initrd with, say, rz on it > - use this initrd to construct the initrd you're really going to use > - switch over to the new initrd using pivot_root > > Advantages: > - no kernel hack needed > - you can use a real protocol, with error detection, sliding windows, > etc., e.g. Kermit or Zmodem > - you can also use a different destination than initrd, e.g. ramfs > may be more desirable > > - - Werner > > - -- > _________________________________________________________________________ > / Werner Almesberger, ICA, EPFL, CH werner.almesberger@ica.epfl.ch / > /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/ > > Please read the FAQ at http://www.tux.org/lkml/ > > ------------------------------ > > From: "Jeff V. Merkey" <jmerkey@timpanogas.com> > Date: Mon, 14 Aug 2000 05:15:35 -0600 > Subject: Re: socket->ops->connect() impossible in-kernel > > Update. I got this working but for future reference to folks, the > kernel functions in_aton() and in_ntoa() if passed a '\n' or '\r' > character at the end of the IP address string, will totally garbage the > TCPIP address into 255.255.255.255 then attempt to connect, which > results in the tcp_v4 functions in-kernel malfunctioning. If you pass > ip address strings as text in kernel mode, be certain to remove any > trailing '\r' or '\n' characters before calling in_aton() or you will > see sock->ops->connect() hang when attempting a SOCK_STREAM connection > operation. > > This shows up on 2.2.17 > > :-) > > Jeff > > "Jeff V. Merkey" wrote: > > > > If you open s socket and pass the handle into user space, then connect > > on SOCK_STREAM works from user space, but does not seem to work in > > kernel space (hangs on signal). I noticed tht ncpfs, smbfs, nbd, and > > just about every other drivers opens the socket in user space and > > connects then passes the socket handle into the drivers via an ioctl(). > > The only exception seems to be the /net/sunrpc stuff. > > > > connecting in kernel seems to be a "jolting" experience. I see hangs, > > -512, -98, -111, and -115 errors returned in an arbitrary manner. This > > seems busted on 2.2.17. > > > > Is it just a bad idea to use connect() in-kernel? > > > > Jeff > > Please read the FAQ at http://www.tux.org/lkml/ > > ------------------------------ > > From: Alan Cox <alan@lxorguk.ukuu.org.uk> > Date: Mon, 14 Aug 2000 12:13:34 +0100 (BST) > Subject: Re: devfs / eth micro-problems > > > Thus, the name is assigned already when the setup function > > is called, and the name assigned is independent of boot > > parameters. > > That is the idea. If the registration fails the name is dropped so > gets assigned to the next probe it does > > > Before allocating a name, init_netdev calls > > netdev_boot_setup_check and this does some extremely > > ugly junk. If the kernel was booted with parameters > > ok this should be happening after the name is assigned and doing > comparisons not assignment of the string > > > [Another strange thing is that net/ethernet/eth.c:eth_setup() > > is precisely identical to net/core/dev.c:netdev_boot_setup(). > > It is __init, but still..] > > One of those probably needs to go - Im not really hacking 2.4 tho > > > but unfortunately I see that they threw out everything > > before July 1st. No doubt someone can point me to a place > > that has June 2000?] > > I believe tux.org has one somewhere > > > Please read the FAQ at http://www.tux.org/lkml/ > > ------------------------------ > > From: Alan Cox <alan@lxorguk.ukuu.org.uk> > Date: Mon, 14 Aug 2000 12:16:02 +0100 (BST) > Subject: Re: Linux 2.2.17pre16 CPU detection wrong > > > I have a system with two Celerons. They have always been detected by > > previous kernels correctly as Celerons with 128kb cache. 2.2.17pre16 > > however detects them as Mobile Pentium II's with no cache. Not > > surprisingly, performance now bites. > > I doubt its touching the performance much, when was the last kernel that > correctly identified your Celeron ? > > > Please read the FAQ at http://www.tux.org/lkml/ > > ------------------------------ > > From: Adrian Bunk <bunk@fs.tum.de> > Date: Mon, 14 Aug 2000 13:29:16 +0200 (CEST) > Subject: linux/Documentation/sound/via82cxxx.txt is missing in 2.2.17-pre16 > > Hi, > > linux/drivers/sound/via82cxxx_audio.c in 2.2.17-pre16 refers to > linux/Documentation/sound/via82cxxx.txt, but this file isn't there. It's > in the 2.4.0-testX kernels and it would be good if it could be included in > the 2.2 kernels, too. > > Thanks, > Adrian > > - -- > A "No" uttered from deepest conviction is better and greater than a > "Yes" merely uttered to please, or what is worse, to avoid trouble. > -- Mahatma Ghandi > > > Please read the FAQ at http://www.tux.org/lkml/ > > ------------------------------ > > From: Michael Rothwell <rothwell@flyingbuttmonkeys.com> > Date: Mon, 14 Aug 2000 07:29:44 -0400 > Subject: Re: NTFS-like streams? > > "Theodore Y. Ts'o" wrote: > > > Is this enough to convince you that trying to emulate Extended > > Attributes in terms of Named Streams is terminally broken?!? > > No. > > > > The other question which this of course raises is what happens if a > > filesystem has *both* named streams and extended attributes? And in > > fact, NTFSv5 (shipped with the W2K bug) does in fact have both. This > > should hopefully prove to you that Extended Attributes and Named Streams > > are fundamentally different. > > Please explain a little better. > > - -M > > Please read the FAQ at http://www.tux.org/lkml/ > > ------------------------------ > > From: Michael Rothwell <rothwell@flyingbuttmonkeys.com> > Date: Mon, 14 Aug 2000 07:34:55 -0400 > Subject: Re: NTFS-like streams? > > Rogier Wolff wrote: > > > tar copyability > > unpackability on ext2fs > > All filesystems may be no different than Ext2, then? > > Legitimate question, don't just flame me. > > - -M > > Please read the FAQ at http://www.tux.org/lkml/ > > ------------------------------ > > From: tkwriter@vanc.igs.net > Date: Mon, 14 Aug 2000 02:52:40 -0700 > Subject: Documentation Specialist Seeking Contract Work > > Documentation Specialists Seeking Contract Work - Technical Writing, > graphics, Robohelp, HTML, SGML, etc. > > Senior technical writers, project leaders and electronic documentation > specialists seek contract work. Clients have included companies such > as Microsoft and Koch Petroleum. Excellent communication skills, able > to work with all levels of the company from programmers to CEO. > Excellent background in technical, marketing and creative writing. > Familiar with educational material as well as e-commerce. > Writing samples, full resume and references available on request. > > Experience in creating both published and online documentation. > > REQUIRED: > > Prefer Corp to Corp Sole relationship directly with the client. > Agents are also welcome in the same capacity. > > Production is done at our facility. We are fully equipped. > > PLEASE REPLY ONLY BY PHONE > Contact - Casey Lea - > > TO INQUIRE ABOUT SERVICES, AVAILABILITY, OR TO CONFIRM REMOVAL FROM OUR LIST > CALL 604-685-8348 PST > > Rates: Fees are charged by the hour or by the project. > > - ------------------- > This message is sent in compliance of the new e-mail bill: SECTION 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618, > > http://www.senate.gov/~murkowski/commercialemail/S771index.html_____________ ______________________________________________ > This Message was Composed by a user of Extractor Pro '98 Bulk E- Mail Software. If > you wish to be removed from this advertiser's future mailings, please reply > with the subject "Remove" and this software will automatically block you > from their future mailings. > > > > Please read the FAQ at http://www.tux.org/lkml/ > > ------------------------------ > > From: R.E.Wolff@BitWizard.nl (Rogier Wolff) > Date: Mon, 14 Aug 2000 13:58:17 +0200 (MEST) > Subject: Re: NTFS-like streams? > > Michael Rothwell wrote: > > Rogier Wolff wrote: > > > > > tar copyability > > > unpackability on ext2fs > > > > All filesystems may be no different than Ext2, then? > > No. > > But the current "HFS workaround" makes the filesystem look as a normal > enough filesystem, so that if you tar it on HFS and then untar it on > either HFS or ext2, it works. > > Linus' suggestion of having a mix between a file and a dir is > interesting, but is not representable by a normal ext2fs, or > TAR. Having to extend the TAR format is a pain in the ass. Losing info > when you untar onto an ext2fs is also annoying. A friend of mine has a > Linux fileserver that is used to share files between his apple and his > windows machine. The current way that atalkd stores files is the same > as that HFS exports stuff. This means that everything is > interoperable. > > I think that the "presentation" side can be extended to do arbitrary > named streams. I think that implementation problems should be fixed as > implementation problems, and not pushed to the design phase. Linus is > trying to promote a solution because he thinks it will be easier to > implement. As I don't know anything about the implementation, I hope > that I'm less biased to think about the troubles in the implementation > :-) > > Roger. > > - -- > ** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 ** > *-- BitWizard writes Linux device drivers for any device you may have! --* > * Common sense is the collection of * > ****** prejudices acquired by age eighteen. -- Albert Einstein ******** > > Please read the FAQ at http://www.tux.org/lkml/ > > ------------------------------ > > From: Michael Rothwell <rothwell@flyingbuttmonkeys.com> > Date: Mon, 14 Aug 2000 07:47:03 -0400 > Subject: Re: NTFS-like streams? > > wingel@t1.ctrl-c.liu.se wrote: > > > What is the basic reason why this directory can't live in a special > > directory called ".fork"? So instead of doing "cd file-with-forks" > > one does "cd .fork/file-with-forks"? > > > How about ".LinuxDouble" ;) > > - -M > > Please read the FAQ at http://www.tux.org/lkml/ > > ------------------------------ > > From: Michael Rothwell <rothwell@flyingbuttmonkeys.com> > Date: Mon, 14 Aug 2000 08:14:10 -0400 > Subject: Re: NTFS-like streams? > > Rogier Wolff wrote: > > > Linus' suggestion of having a mix between a file and a dir is > > interesting, but is not representable by a normal ext2fs > > filesystems that support streams/forks/EAs are _not_ > like ext2, and it seems wrong to make them try to > squeeze into ext2's shoes. > > , or > > TAR. Having to extend the TAR format is a pain in the ass. Losing info > > when you untar onto an ext2fs is also annoying. > > So there will be a "star" utility for streams filesystems, > which one day will get merged into regular tar. Or "spax" > or whatever. > > > A friend of mine has a > > Linux fileserver that is used to share files between his apple and his > > windows machine. The current way that atalkd stores files is the same > > as that HFS exports stuff. This means that everything is > > interoperable. > > HFS and netatalk were written specifically to agree > with each other on that hack. Netatalk also supports > other local FS representations. I think HFS does as > well ("-o netatalk" or whatever the option is makes > HFS output its forks in netatalk-compatible format). > > It would be nice to have a universal representation > of streams/EAs/forks for FSes that support them, without > using ".LinuxDouble" chicanery. If all EAs are stored > in a separate directory, I imagine they will be orphaned > all the time. I know this happens in HFS. I usually walked > over to a Mac (when I had Macs) to manipulate files, rather > than do it from the linux box, because I would break the > filesystem doing it frm Linux. With the HFS hack, I can only > move/rename/delete whole directories at a time to avoid > filesystem corruption. Or tediously go into each > .AppleWhatever directory, find all the orphaned resources, > and move those as well. > > > - -Michael > > Please read the FAQ at http://www.tux.org/lkml/ > > ------------------------------ > > End of linux-kernel-digest V1 #1322 > *********************************** > > To subscribe to linux-kernel-digest, send the command: > > subscribe linux-kernel-digest > > in the body of a message to "Majordomo@vger.rutgers.edu". If you want > to subscribe something other than the account the mail is coming from, > such as a local redistribution list, then append that address to the > "subscribe" command; for example, to subscribe "local-linux-kernel": > > subscribe linux-kernel-digest local-linux-kernel@your.domain.net > > A non-digest (direct mail) version of this list is also available; to > subscribe to that instead, replace all instances of "linux-kernel-digest" > in the commands above with "linux-kernel". >
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |