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/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:35 EST