Re: LANANA: To Pending Device Number Registrants
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yesterday, Timothy A. Seufert ([EMAIL PROTECTED]) wrote: > Why not take it a step further than just devices? This is a perfect > model for supporting named forks. Because this only works on filesystems where directories can't themselves have named forks (or streams, or whatever you wish to call them) associated with them. Read the archives on this issue :) Mo. - -- Mo McKinlay [EMAIL PROTECTED] http://ekto.org Read http://www.ietf.org/rfc/rfc1855.txt - - GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.5 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjsCod0ACgkQRcGgB3aidflJyQCfdjh+o8vZvzZLfowM5QoLGICy tmAAoMIF4DcyqTep43Hd2/9X9tfeIH9X =cKMC -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yesterday, Timothy A. Seufert ([EMAIL PROTECTED]) wrote: Why not take it a step further than just devices? This is a perfect model for supporting named forks. Because this only works on filesystems where directories can't themselves have named forks (or streams, or whatever you wish to call them) associated with them. Read the archives on this issue :) Mo. - -- Mo McKinlay [EMAIL PROTECTED] http://ekto.org Read http://www.ietf.org/rfc/rfc1855.txt - - GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.5 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjsCod0ACgkQRcGgB3aidflJyQCfdjh+o8vZvzZLfowM5QoLGICy tmAAoMIF4DcyqTep43Hd2/9X9tfeIH9X =cKMC -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Version 2.4.1 cannot be built.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wednesday, Richard B. Johnson ([EMAIL PROTECTED]) wrote: > Now just a cotton-picken minute. When was the last time you > accessed that site? I spent most of last night looking through > EMPTY directories with files that are invisible to ftp but > (sometimes) show with their `ls`, and never with nlist. > Maybe you can still download stuff if you are running from a > Web Crawler, but it doesn't work with `ftp` anymore. We've had no problem reports, and it works fine for me. Mo. - -- Mo McKinlay -- GNU Webmaster [EMAIL PROTECTED] - - GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjp7M0MACgkQRcGgB3aidfnX9wCgjiWJvUlgfRzNGfOMJZJ1rmzR 9XMAoNXVFRJzC5aRUOAQo0moWuchmAsO =yDvE -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: named streams, extended attributes, and posix
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Today, Michael Rothwell ([EMAIL PROTECTED]) wrote:
> So, openstream() is probably the most painless way to get named streams
> support into Linux in the immediate future. Openstream() will have to
> fail on filesystems that do not support streams, ideally without
> changing those filesystems.
Agree - I'd imagine with the same error that trying to symlink on a
filesystem which does not support symlinks produces ("Operation not
permitted"?).
> And as long as we're adding a system call to
> deal with streams, we should consider adding the functions for extended
> attributes at the same time.
Agree.
> >From http://www.flyingbuttmonkeys.com/streams-on-posix.txt ...
>
> Minimum VFS Support
> vop_eattr_get - read an EA
> vop_eattr_set - set an EA
> vop_eattr_remove - remove an EA
> vop_eattr_list - list the EAs like vop_readdir would a directory.
>
> Optional Support
> vop_eattr_create - Create an EA or error if it exists.
> vop_eattr_multi - perform a sequence of EA vops atomically.
> vop_eattr_rename - change the name of an EA
> vop_eattr_serialize - export all the EAs as a stream of entries.
>
> Thoughts? You mught want to refer back to the paper to get the whole EAs
> proposal...
I shall, and get back to you this evening (workworkworkwork... :)
Mo.
- --
Mo McKinlay
[EMAIL PROTECTED]
- -
GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAjp1kGIACgkQRcGgB3aidfmBWQCfSODBdYvh0QhqwxHUWB3IGUxg
NY4AoLG1i01AmjYASQwwQMh58t2b1Ut7
=bwEX
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: named streams, extended attributes, and posix
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Today, Michael Rothwell ([EMAIL PROTECTED]) wrote:
So, openstream() is probably the most painless way to get named streams
support into Linux in the immediate future. Openstream() will have to
fail on filesystems that do not support streams, ideally without
changing those filesystems.
Agree - I'd imagine with the same error that trying to symlink on a
filesystem which does not support symlinks produces ("Operation not
permitted"?).
And as long as we're adding a system call to
deal with streams, we should consider adding the functions for extended
attributes at the same time.
Agree.
From http://www.flyingbuttmonkeys.com/streams-on-posix.txt ...
Minimum VFS Support
vop_eattr_get - read an EA
vop_eattr_set - set an EA
vop_eattr_remove - remove an EA
vop_eattr_list - list the EAs like vop_readdir would a directory.
Optional Support
vop_eattr_create - Create an EA or error if it exists.
vop_eattr_multi - perform a sequence of EA vops atomically.
vop_eattr_rename - change the name of an EA
vop_eattr_serialize - export all the EAs as a stream of entries.
Thoughts? You mught want to refer back to the paper to get the whole EAs
proposal...
I shall, and get back to you this evening (workworkworkwork... :)
Mo.
- --
Mo McKinlay
[EMAIL PROTECTED]
- -
GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAjp1kGIACgkQRcGgB3aidfmBWQCfSODBdYvh0QhqwxHUWB3IGUxg
NY4AoLG1i01AmjYASQwwQMh58t2b1Ut7
=bwEX
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Renaming lost+found
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Today, H. Peter Anvin ([EMAIL PROTECTED]) wrote: > Hello people... the original question was: can lost+found be > *renamed*, i.e. does the tools (e2fsck ) use "/lost+found" by name, > or by inode? As far as I know it always uses the same inode number > (11), but I don't know if that is anywhere enforced. I seem to recall e2fsck complaining when I renamed lost+found, but that may well be a consistency check. Don't quote me on this, though. Mo. - -- Mo McKinlay [EMAIL PROTECTED] - - GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjp0kgYACgkQRcGgB3aidfngIACdH4Ze9KRUS/jExERYM0Jt0n4e WyMAoKxzOr7KnVeEoHCHKlCBjNcncx8U =myDq -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Renaming lost+found
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Today, H. Peter Anvin ([EMAIL PROTECTED]) wrote: Hello people... the original question was: can lost+found be *renamed*, i.e. does the tools (e2fsck c) use "/lost+found" by name, or by inode? As far as I know it always uses the same inode number (11), but I don't know if that is anywhere enforced. I seem to recall e2fsck complaining when I renamed lost+found, but that may well be a consistency check. Don't quote me on this, though. Mo. - -- Mo McKinlay [EMAIL PROTECTED] - - GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjp0kgYACgkQRcGgB3aidfngIACdH4Ze9KRUS/jExERYM0Jt0n4e WyMAoKxzOr7KnVeEoHCHKlCBjNcncx8U =myDq -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Today, Admin Mailing Lists ([EMAIL PROTECTED]) wrote: > > And the lord spake, saying, "First shalt thou write thy holy code. Indenting > > shalt thou count to three, no more, no less. Three shalt be the spaces thou > > shalt count, and the number of the counting shalt be three. Four shalt thou > > not count, nor count thou two, excepting that thou then proceedeth to three. > > Eight is right out. Once the number three, being the third number be > > reached, shalt thou move towards indenting thy next line .. > now I know why I never read the bible. ..or Monty Python... - -- Mo McKinlay [EMAIL PROTECTED] - - GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjprZWUACgkQRcGgB3aidfnz0gCgqOGt7dg3cZH/uDz0Vpe/P9Fe ALsAn2y2L/D9e1QRWTb6jDSM+kvsrShr =3D28 -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [OT?] Coding Style
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Today, Admin Mailing Lists ([EMAIL PROTECTED]) wrote: And the lord spake, saying, "First shalt thou write thy holy code. Indenting shalt thou count to three, no more, no less. Three shalt be the spaces thou shalt count, and the number of the counting shalt be three. Four shalt thou not count, nor count thou two, excepting that thou then proceedeth to three. Eight is right out. Once the number three, being the third number be reached, shalt thou move towards indenting thy next line .. now I know why I never read the bible. ..or Monty Python... - -- Mo McKinlay [EMAIL PROTECTED] - - GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjprZWUACgkQRcGgB3aidfnz0gCgqOGt7dg3cZH/uDz0Vpe/P9Fe ALsAn2y2L/D9e1QRWTb6jDSM+kvsrShr =3D28 -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Is sendfile all that sexy?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Today, Linus Torvalds ([EMAIL PROTECTED]) wrote: > Just wait. My crystal ball is infallible. One of these days, that line will be your downfall :-) *grins* Mo. - -- Mo McKinlay [EMAIL PROTECTED] - - GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjpp/ssACgkQRcGgB3aidfmcagCgkieTFD77O+Xqn+nmcaoiYERh UwwAoIL8cWZPdaKine4fZ4fJmQqwTvBZ =i1Ax -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Is sendfile all that sexy?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Today, Linus Torvalds ([EMAIL PROTECTED]) wrote: Just wait. My crystal ball is infallible. One of these days, that line will be your downfall :-) *grins* Mo. - -- Mo McKinlay [EMAIL PROTECTED] - - GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjpp/ssACgkQRcGgB3aidfmcagCgkieTFD77O+Xqn+nmcaoiYERh UwwAoIL8cWZPdaKine4fZ4fJmQqwTvBZ =i1Ax -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: named streams, extended attributes, and posix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Today, Michael Rothwell ([EMAIL PROTECTED]) wrote: > Mo McKinlay wrote: > > > Nono, that's not what I mean - each of the filesystems fails if it > > doesn't support what you're trying to do, that's given - but having a > > different delimeter registered by the filesystem (and hence the > > possibility of every single filesystem using a different delimeter) brings > > about a completely different kind of inconsistency. > True. Which is why I'd prefer a standard delimiter. ":" seems to be the > top candidate. I would too, but POSIX won't let us unless we start enforcing side-effect rules for all filesystems. Hence why I came up with openstream() :) Mo. - -- Mo McKinlay [EMAIL PROTECTED] - - GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjpobHEACgkQRcGgB3aidfnOyQCeNwj2WYbQd059F/JurCkcruED cWEAoMO0P8eH3BAzpRkzcP3RkVDiEXOl =siV3 -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: named streams, extended attributes, and posix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Today, Michael Rothwell ([EMAIL PROTECTED]) wrote: > Oh, undoubtedly. But NTFS already disallows several characters in valid > filenames. This also violates the "consistent abstract interface." But > it's reality. Nono, that's not what I mean - each of the filesystems fails if it doesn't support what you're trying to do, that's given - but having a different delimeter registered by the filesystem (and hence the possibility of every single filesystem using a different delimeter) brings about a completely different kind of inconsistency. Mo. - -- Mo McKinlay [EMAIL PROTECTED] - - GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjpoZlQACgkQRcGgB3aidfnnNACcC99aXvrG1lsbEv5rr8wpGrTe ZScAn1TCpbviEGzWn6UGHhqTgQVVSqVp =UL3r -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: named streams, extended attributes, and posix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Today, Michael Rothwell ([EMAIL PROTECTED]) wrote: > The filesystem, when registering that it supports the "named streams" > namespace, could specify its preferred delimiter to the VFS as well. > Ext4 could use /directory/file/stream, and NTFS could use > /directory/file:stream. Erk - nice from a programming point of view, horrible from a consistency one. The nice thing about VFS is that it provides a consistent abstract interface - I'd place a small amount of money on the fact that Al Viro would probably flame you to high heaven for that last suggestion if he was paying much attention to this thread :-) - -- Mo McKinlay [EMAIL PROTECTED] - - GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjpoYe4ACgkQRcGgB3aidfn2RQCfa1nnClzSXxBCB0XnJ35RmOcm ysoAoJSg+USBkDCp4PKcX5iD0JQQvXw9 =Lkci -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: named streams, extended attributes, and posix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Today, Michael Rothwell ([EMAIL PROTECTED]) wrote: > Thanks. I think having the option of the namespace augmentation would be > useful, in terms of supporting existing filesystems. On NTFS, ":" is not > a legal filename character anyway. The namespace augmentation suggested > in the paper would allow filesystems like NTFS to work as they should, > and all other filesystems to ignore it. This was the tack I originally took - but I realised it would eventually cause problems - not least because rather than returning an error when a user does something not supported like most actions do, the operation behaves differently - which is a little confusing. (Take symbolic linking, for example - if you ln -s on VFAT, you get 'operation not permitted' - named stream/EA operations on a filesystem that doesn't support them should return the same, IMHO). Also, I don't like the idea of bypassing POSIX in this manner (using ':' as a delimeter), even if the underlying filesystem *may* not support it. What's to say that ext4 (or whatever) won't support named streams, but still allow ':'? Your solution as it stands would break in that situation (assuming I've not missed something :) Mo. - -- Mo McKinlay [EMAIL PROTECTED] - - GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjpoW04ACgkQRcGgB3aidfncVgCgm19oUQqgGSW7XNCZwoWB/bIj 2W0AoK64xCfbjcamj3F5fDyBtVg8KQBa =PEu2 -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: named streams, extended attributes, and posix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > Well, EAs are accessed via a special API. The paper also covers that. > Streams, however, are by nature accessed as files; this is what makes > them not EAs. EAs are set and retrieved atomically. Streams can be used > with open(), seek(), read(), write(), etc. This is actually more "unixy" > than EAs, as the usual set of Unix functions and tools can work with > streams unmodified; i.e., without knowledge of a special API. Of course, > cp() is the exception. It would have to be able to enumerate and copy > all the streams. Hokay, I've skimmed the paper, most of it makes sense, although I still think the additional separator is a bad idea (which I know isn't what I said last time around, originally, but I've had a chance to ponder a little more since :). Hence, I reckon we should have: openstream(file, stream, flags) Where 'file' should be an fd (although i'm sure the VFS gods will think of plenty of reasons why this is a bad idea, at which point I'll conventiently change my mind ;). Stream is simply the name of the stream, flags are as with open() (O_RDONLY, et al). openstream() then returns an fd which can be read/written/sendfiled/closed as the programmer wishes. How daft does this sound? Apart from the additional of a new open()-type call, your paper seems to be fairly solid. Mo. - -- Mo McKinlay [EMAIL PROTECTED] - - GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjpoVmMACgkQRcGgB3aidfnLuACfSZqvswA0B1xnWilVWQcSHubM yQAAn2T+RFRN3qznuQ8wOeWXxIBVGb45 =SUm5 -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: named streams, extended attributes, and posix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Today, Michael Rothwell ([EMAIL PROTECTED]) wrote: > Unfortunately, unix allows everything but "/" in filenames. This was > probably a mistake, as it makes it nearly impossible to augment the > namespace, but it is the reality. > Did you read the "new namespace" section of the paper? I've not, so pardon me if I make a bad assumption (and slap me for it, too), but doesn't introducing a new namespace segregate the streams from the files/directories, thus introducing an artifical separation which isn't really there? (Pretty much why I'm more in favour of a specific API for reading streams, extended attributes and whatnot, over any of the other solutions thus suggested). Mo. - -- Mo McKinlay [EMAIL PROTECTED] - - GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjpoTQMACgkQRcGgB3aidfmurACdEb+w6gwUW7fc4FVdZ7umHlDs /AgAoN8SOXejiKDd8G/KPVTP7qZwzhnO =Ld9D -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: named streams, extended attributes, and posix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Today, Michael Rothwell ([EMAIL PROTECTED]) wrote: Unfortunately, unix allows everything but "/" in filenames. This was probably a mistake, as it makes it nearly impossible to augment the namespace, but it is the reality. Did you read the "new namespace" section of the paper? I've not, so pardon me if I make a bad assumption (and slap me for it, too), but doesn't introducing a new namespace segregate the streams from the files/directories, thus introducing an artifical separation which isn't really there? (Pretty much why I'm more in favour of a specific API for reading streams, extended attributes and whatnot, over any of the other solutions thus suggested). Mo. - -- Mo McKinlay [EMAIL PROTECTED] - - GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjpoTQMACgkQRcGgB3aidfmurACdEb+w6gwUW7fc4FVdZ7umHlDs /AgAoN8SOXejiKDd8G/KPVTP7qZwzhnO =Ld9D -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: named streams, extended attributes, and posix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Well, EAs are accessed via a special API. The paper also covers that. Streams, however, are by nature accessed as files; this is what makes them not EAs. EAs are set and retrieved atomically. Streams can be used with open(), seek(), read(), write(), etc. This is actually more "unixy" than EAs, as the usual set of Unix functions and tools can work with streams unmodified; i.e., without knowledge of a special API. Of course, cp() is the exception. It would have to be able to enumerate and copy all the streams. Hokay, I've skimmed the paper, most of it makes sense, although I still think the additional separator is a bad idea (which I know isn't what I said last time around, originally, but I've had a chance to ponder a little more since :). Hence, I reckon we should have: openstream(file, stream, flags) Where 'file' should be an fd (although i'm sure the VFS gods will think of plenty of reasons why this is a bad idea, at which point I'll conventiently change my mind ;). Stream is simply the name of the stream, flags are as with open() (O_RDONLY, et al). openstream() then returns an fd which can be read/written/sendfiled/closed as the programmer wishes. How daft does this sound? Apart from the additional of a new open()-type call, your paper seems to be fairly solid. Mo. - -- Mo McKinlay [EMAIL PROTECTED] - - GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjpoVmMACgkQRcGgB3aidfnLuACfSZqvswA0B1xnWilVWQcSHubM yQAAn2T+RFRN3qznuQ8wOeWXxIBVGb45 =SUm5 -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: named streams, extended attributes, and posix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Today, Michael Rothwell ([EMAIL PROTECTED]) wrote: Thanks. I think having the option of the namespace augmentation would be useful, in terms of supporting existing filesystems. On NTFS, ":" is not a legal filename character anyway. The namespace augmentation suggested in the paper would allow filesystems like NTFS to work as they should, and all other filesystems to ignore it. This was the tack I originally took - but I realised it would eventually cause problems - not least because rather than returning an error when a user does something not supported like most actions do, the operation behaves differently - which is a little confusing. (Take symbolic linking, for example - if you ln -s on VFAT, you get 'operation not permitted' - named stream/EA operations on a filesystem that doesn't support them should return the same, IMHO). Also, I don't like the idea of bypassing POSIX in this manner (using ':' as a delimeter), even if the underlying filesystem *may* not support it. What's to say that ext4 (or whatever) won't support named streams, but still allow ':'? Your solution as it stands would break in that situation (assuming I've not missed something :) Mo. - -- Mo McKinlay [EMAIL PROTECTED] - - GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjpoW04ACgkQRcGgB3aidfncVgCgm19oUQqgGSW7XNCZwoWB/bIj 2W0AoK64xCfbjcamj3F5fDyBtVg8KQBa =PEu2 -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: named streams, extended attributes, and posix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Today, Michael Rothwell ([EMAIL PROTECTED]) wrote: The filesystem, when registering that it supports the "named streams" namespace, could specify its preferred delimiter to the VFS as well. Ext4 could use /directory/file/stream, and NTFS could use /directory/file:stream. Erk - nice from a programming point of view, horrible from a consistency one. The nice thing about VFS is that it provides a consistent abstract interface - I'd place a small amount of money on the fact that Al Viro would probably flame you to high heaven for that last suggestion if he was paying much attention to this thread :-) - -- Mo McKinlay [EMAIL PROTECTED] - - GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjpoYe4ACgkQRcGgB3aidfn2RQCfa1nnClzSXxBCB0XnJ35RmOcm ysoAoJSg+USBkDCp4PKcX5iD0JQQvXw9 =Lkci -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: named streams, extended attributes, and posix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Today, Michael Rothwell ([EMAIL PROTECTED]) wrote: Oh, undoubtedly. But NTFS already disallows several characters in valid filenames. This also violates the "consistent abstract interface." But it's reality. Nono, that's not what I mean - each of the filesystems fails if it doesn't support what you're trying to do, that's given - but having a different delimeter registered by the filesystem (and hence the possibility of every single filesystem using a different delimeter) brings about a completely different kind of inconsistency. Mo. - -- Mo McKinlay [EMAIL PROTECTED] - - GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjpoZlQACgkQRcGgB3aidfnnNACcC99aXvrG1lsbEv5rr8wpGrTe ZScAn1TCpbviEGzWn6UGHhqTgQVVSqVp =UL3r -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: named streams, extended attributes, and posix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Today, Michael Rothwell ([EMAIL PROTECTED]) wrote: Mo McKinlay wrote: Nono, that's not what I mean - each of the filesystems fails if it doesn't support what you're trying to do, that's given - but having a different delimeter registered by the filesystem (and hence the possibility of every single filesystem using a different delimeter) brings about a completely different kind of inconsistency. True. Which is why I'd prefer a standard delimiter. ":" seems to be the top candidate. I would too, but POSIX won't let us unless we start enforcing side-effect rules for all filesystems. Hence why I came up with openstream() :) Mo. - -- Mo McKinlay [EMAIL PROTECTED] - - GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjpobHEACgkQRcGgB3aidfnOyQCeNwj2WYbQd059F/JurCkcruED cWEAoMO0P8eH3BAzpRkzcP3RkVDiEXOl =siV3 -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: named streams, extended attributes, and posix
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Yesterday, Peter Samuelson ([EMAIL PROTECTED]) wrote:
> Yeah, I agree, 'file/stream' is lousy syntax as well. If it weren't
> for the possibility of having streams on directories, it would almost
> be acceptible. I still don't know which (':' or '/') is the worse
> hack.
Me neither :/
> As I've said elsewhere in this thread, I can't think of *any* clean way
> to shoehorn forks into nice, transparent posix calls. It really wants
> a new API.
Likewise. This was my standpoint the last time around - a clear concise
portable API for accessing streams (even if it *started out*
Linux-specific) - without imposing silly semantics on existing
applications which currently ignore streams anyway.
Mo.
- --
Mo McKinlay
[EMAIL PROTECTED]
- -
GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAjpnYGQACgkQRcGgB3aidfmWBQCfXgNq/vqltt76mApoDiNI9HnH
ws8AoJZ2vvlH1iCAeUu7yktWWN0Bncc3
=gEmD
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: named streams, extended attributes, and posix
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Yesterday, Peter Samuelson ([EMAIL PROTECTED]) wrote:
Yeah, I agree, 'file/stream' is lousy syntax as well. If it weren't
for the possibility of having streams on directories, it would almost
be acceptible. I still don't know which (':' or '/') is the worse
hack.
Me neither :/
As I've said elsewhere in this thread, I can't think of *any* clean way
to shoehorn forks into nice, transparent posix calls. It really wants
a new API.
Likewise. This was my standpoint the last time around - a clear concise
portable API for accessing streams (even if it *started out*
Linux-specific) - without imposing silly semantics on existing
applications which currently ignore streams anyway.
Mo.
- --
Mo McKinlay
[EMAIL PROTECTED]
- -
GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAjpnYGQACgkQRcGgB3aidfmWBQCfXgNq/vqltt76mApoDiNI9HnH
ws8AoJZ2vvlH1iCAeUu7yktWWN0Bncc3
=gEmD
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: named streams, extended attributes, and posix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yesterday, Peter Samuelson ([EMAIL PROTECTED]) wrote: > > [Michael Rothwell] > > It seems that if you move a file with a colon -- "file:colon" -- in > > the name from Ext2 to "StreamFS," you would end up with a file named > > "file" with a stream named "colon". When copying back, you would get > > "file:colon" back. > > What if you copy both 'filename' and 'filename:ext' onto the same fs? > Do they get combined into one file? That to me violates principle of > least surprise. The fs should just mangle filenames it doesn't agree > with, like the existing legacy filesystems already do. > Any semantics by which 'filename:stream' and 'filename' refer to the > same file would be b0rken. If instead you use 'filename/stream' > syntax, at least that is an illegal filename on *all* Linux > filesystems, so this particular point of confusion does not come up. Urgh. We went through this last time around. What happens to directories with streams? If they are also dirname/stream, what happens when you have a file called 'stream' within 'dirname'? Also, it makes it appear that files with streams are directories, which they are not, so applying the directory accessor to them violates the principle of least suprise and is misleading. Apply a new accessor (which the colon would be great for, as it is already used for this purpose -- apart from the fact that POSIX already allows applications to use it in filenames). - -- Mo McKinlay [EMAIL PROTECTED] - - GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjpk6V8ACgkQRcGgB3aidfkLgACfZZ1+5klZUB/NKTDK9PoRlV2H ddcAoKBJSYA5/02Y8+dV9zyZHi5hUCeK =ptqG -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: named streams, extended attributes, and posix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yesterday, Peter Samuelson ([EMAIL PROTECTED]) wrote: [Michael Rothwell] It seems that if you move a file with a colon -- "file:colon" -- in the name from Ext2 to "StreamFS," you would end up with a file named "file" with a stream named "colon". When copying back, you would get "file:colon" back. What if you copy both 'filename' and 'filename:ext' onto the same fs? Do they get combined into one file? That to me violates principle of least surprise. The fs should just mangle filenames it doesn't agree with, like the existing legacy filesystems already do. Any semantics by which 'filename:stream' and 'filename' refer to the same file would be b0rken. If instead you use 'filename/stream' syntax, at least that is an illegal filename on *all* Linux filesystems, so this particular point of confusion does not come up. Urgh. We went through this last time around. What happens to directories with streams? If they are also dirname/stream, what happens when you have a file called 'stream' within 'dirname'? Also, it makes it appear that files with streams are directories, which they are not, so applying the directory accessor to them violates the principle of least suprise and is misleading. Apply a new accessor (which the colon would be great for, as it is already used for this purpose -- apart from the fact that POSIX already allows applications to use it in filenames). - -- Mo McKinlay [EMAIL PROTECTED] - - GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjpk6V8ACgkQRcGgB3aidfkLgACfZZ1+5klZUB/NKTDK9PoRlV2H ddcAoKBJSYA5/02Y8+dV9zyZHi5hUCeK =ptqG -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Journaling: Surviving or allowing unclean shutdown?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Today, David Lang ([EMAIL PROTECTED]) wrote: > On Thu, 4 Jan 2001, Mo McKinlay wrote: > > > > The off button need not and _does not_ remove power instantly (if at > > > all) on many appliances. > > > > Indeed - but unplugging your VCR from the wall won't harm it. Everyone > > knows the power button on a TV/VCR/etc doesn't actually kill the power, > > just reduce consumption (i.e., standby mode). But unplugging it at the > > wall doesn't have any detrimental effects - doing that to a PC will. > > if you change that statement to "usually won't harm it" I agree with you > (I have had a VCR eat a tape when this was done) Crikey. Most people would consider that a fault in the VCR. Just goes to show how far removed from appliances PCs currently are. - -- Mo McKinlay [EMAIL PROTECTED] - - GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjpUvwcACgkQRcGgB3aidfkR3wCfVTY9NJY8irZ5BNxgQ1jrQWsP 3jIAnjVpIdJtOb66Q1wK451QPH00Q7wH =90Eb -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Journaling: Surviving or allowing unclean shutdown?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > The off button need not and _does not_ remove power instantly (if at > all) on many appliances. Indeed - but unplugging your VCR from the wall won't harm it. Everyone knows the power button on a TV/VCR/etc doesn't actually kill the power, just reduce consumption (i.e., standby mode). But unplugging it at the wall doesn't have any detrimental effects - doing that to a PC will. Being able to change what the power button does is cool, but it does mask the real issue - what happens when you pull the plug, and how do you make it so that it's acceptable? - -- Mo McKinlay [EMAIL PROTECTED] - - GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjpUvcEACgkQRcGgB3aidflzEwCgpYdN7Tp7e1S3HGoTA6JKBS40 +GUAn20lCCVeqJbPzJ5k+qJd1OHsZjqu =YQ4B -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Journaling: Surviving or allowing unclean shutdown?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > for crying out loud, even windows tells the users they need to shutdown > first and gripes at them if they pull the plug. what users are you trying > to protect, ones to clueless to even run windows? > > David Lang > > > > > it's essential for embedded devices. Answer your question? - -- Mo McKinlay [EMAIL PROTECTED] - - GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjpUvNYACgkQRcGgB3aidfmyAgCfRdJT1cIUN5eu28Op6BZrytb5 QEoAnReB9nUaWFIEemV7QJsSkMES32Vi =vGm7 -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Journaling: Surviving or allowing unclean shutdown?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 for crying out loud, even windows tells the users they need to shutdown first and gripes at them if they pull the plug. what users are you trying to protect, ones to clueless to even run windows? David Lang it's essential for embedded devices. Answer your question? - -- Mo McKinlay [EMAIL PROTECTED] - - GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjpUvNYACgkQRcGgB3aidfmyAgCfRdJT1cIUN5eu28Op6BZrytb5 QEoAnReB9nUaWFIEemV7QJsSkMES32Vi =vGm7 -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Journaling: Surviving or allowing unclean shutdown?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The off button need not and _does not_ remove power instantly (if at all) on many appliances. Indeed - but unplugging your VCR from the wall won't harm it. Everyone knows the power button on a TV/VCR/etc doesn't actually kill the power, just reduce consumption (i.e., standby mode). But unplugging it at the wall doesn't have any detrimental effects - doing that to a PC will. Being able to change what the power button does is cool, but it does mask the real issue - what happens when you pull the plug, and how do you make it so that it's acceptable? - -- Mo McKinlay [EMAIL PROTECTED] - - GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjpUvcEACgkQRcGgB3aidflzEwCgpYdN7Tp7e1S3HGoTA6JKBS40 +GUAn20lCCVeqJbPzJ5k+qJd1OHsZjqu =YQ4B -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Journaling: Surviving or allowing unclean shutdown?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Today, David Lang ([EMAIL PROTECTED]) wrote: On Thu, 4 Jan 2001, Mo McKinlay wrote: The off button need not and _does not_ remove power instantly (if at all) on many appliances. Indeed - but unplugging your VCR from the wall won't harm it. Everyone knows the power button on a TV/VCR/etc doesn't actually kill the power, just reduce consumption (i.e., standby mode). But unplugging it at the wall doesn't have any detrimental effects - doing that to a PC will. if you change that statement to "usually won't harm it" I agree with you (I have had a VCR eat a tape when this was done) Crikey. Most people would consider that a fault in the VCR. Just goes to show how far removed from appliances PCs currently are. - -- Mo McKinlay [EMAIL PROTECTED] - - GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjpUvwcACgkQRcGgB3aidfkR3wCfVTY9NJY8irZ5BNxgQ1jrQWsP 3jIAnjVpIdJtOb66Q1wK451QPH00Q7wH =90Eb -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: innd mmap bug in 2.4.0-test12
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > does anyone other than me think that the pm code is *way* too agressive about > spinning down the hard drive? my 256mb laptop (2.2.16) will only spin down the > disk for about 30 seconds before it decides it's got something else it feels > like writing out, and spins back up. Spinnup has got to be more wasteful than > just leaving the drive spinning... Yup, I find this - especially if I hang around in X for a while. - -- " "" " " " " " " " " """ " " " " "" " " "" """ """ "" " " " " "" " """ """ " "" "" """ " " """ " " "" """" "" " "" "" " " """ " " " " "" " " """ " " " "" " " " "" -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Made with pgp4pine iD8DBQE6S7JJRcGgB3aidfkRAhpkAJ9UYVhD+sRqADqUMm2i+UgbuYS8kACgzG4E WhqPEhm6XHixqHpUOFQ4els= =yQKY -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: innd mmap bug in 2.4.0-test12
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 does anyone other than me think that the pm code is *way* too agressive about spinning down the hard drive? my 256mb laptop (2.2.16) will only spin down the disk for about 30 seconds before it decides it's got something else it feels like writing out, and spins back up. Spinnup has got to be more wasteful than just leaving the drive spinning... Yup, I find this - especially if I hang around in X for a while. - -- " "" " " " " " " " " """ " " " " "" " " "" """ """ "" " " " " "" " """ """ " "" "" """ " " """ " " "" """" "" " "" "" " " """ " " " " "" " " """ " " " "" " " " "" -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Made with pgp4pine iD8DBQE6S7JJRcGgB3aidfkRAhpkAJ9UYVhD+sRqADqUMm2i+UgbuYS8kACgzG4E WhqPEhm6XHixqHpUOFQ4els= =yQKY -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ESS device "1998"
Today, Martin Dalecki ([EMAIL PROTECTED]) wrote: > The chip you are talking about is a maestro-3. It's a hybris chip > between a CS and an Alegro. The OSS sound drivers support it > already. > However there is no free driver for it currently out there. > If you get the current maestro open driver to recognize the chip > at least the mixer will start to work. Aha - Many thanks! I shall go and experiment, then :) -- Mo McKinlay [EMAIL PROTECTED] - GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
ESS device "1998"
I recently obtained an HP Omnibook XE2 laptop. It's a reasonably nicely-specced machine, although (unsuprsingly) the hardware isn't too well supported with Linux. I've given up on the internal modem (I'm 90% sure it's some kind of software modem, and I have an external anyway), but I'm trying to get some sort of audio to work via the internal sound device. Here's the output of 'lspci': 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 03) 00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 03) 00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) 00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) 00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) 00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 03) 00:0a.0 CardBus bridge: Texas Instruments PCI1225 (rev 01) 00:0a.1 CardBus bridge: Texas Instruments PCI1225 (rev 01) 00:0d.0 Multimedia audio controller: ESS Technology: Unknown device 1998 00:0d.1 Communication controller: ESS Technology: Unknown device 1999 01:00.0 VGA compatible controller: Silicon Motion, Inc.: Unknown device 0710 (rev a3) 20:00.0 Ethernet controller: Xircom Cardbus Ethernet 10/100 (rev 03) 20:00.1 Serial controller: Xircom Cardbus Ethernet + 56k Modem (rev 03) I'm currently using 2.2.14 (plus whichever patches RH added for their 6.2 release), and it doesn't seem to be supported. So.. simple question, does anybody know if this 'card' is supported in a more recent kernel, or whether there's something in 2.2.14 that works? [As an aside, from watching Windows boot, it seems to have some sort of SoundBlaster compatibility, although it seems to lack MPU401 support or emulation - and any attempts to use the Linux soundblaster stuff seems to fail miserably :/] Any hints/clues/etc welcome. Many thanks, Mo. -- Mo McKinlay [EMAIL PROTECTED] - GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
ESS device 1998
I recently obtained an HP Omnibook XE2 laptop. It's a reasonably nicely-specced machine, although (unsuprsingly) the hardware isn't too well supported with Linux. I've given up on the internal modem (I'm 90% sure it's some kind of software modem, and I have an external anyway), but I'm trying to get some sort of audio to work via the internal sound device. Here's the output of 'lspci': 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 03) 00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 03) 00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) 00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) 00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) 00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 03) 00:0a.0 CardBus bridge: Texas Instruments PCI1225 (rev 01) 00:0a.1 CardBus bridge: Texas Instruments PCI1225 (rev 01) 00:0d.0 Multimedia audio controller: ESS Technology: Unknown device 1998 00:0d.1 Communication controller: ESS Technology: Unknown device 1999 01:00.0 VGA compatible controller: Silicon Motion, Inc.: Unknown device 0710 (rev a3) 20:00.0 Ethernet controller: Xircom Cardbus Ethernet 10/100 (rev 03) 20:00.1 Serial controller: Xircom Cardbus Ethernet + 56k Modem (rev 03) I'm currently using 2.2.14 (plus whichever patches RH added for their 6.2 release), and it doesn't seem to be supported. So.. simple question, does anybody know if this 'card' is supported in a more recent kernel, or whether there's something in 2.2.14 that works? [As an aside, from watching Windows boot, it seems to have some sort of SoundBlaster compatibility, although it seems to lack MPU401 support or emulation - and any attempts to use the Linux soundblaster stuff seems to fail miserably :/] Any hints/clues/etc welcome. Many thanks, Mo. -- Mo McKinlay [EMAIL PROTECTED] - GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ESS device 1998
Today, Martin Dalecki ([EMAIL PROTECTED]) wrote: The chip you are talking about is a maestro-3. It's a hybris chip between a CS and an Alegro. The OSS sound drivers support it already. However there is no free driver for it currently out there. If you get the current maestro open driver to recognize the chip at least the mixer will start to work. Aha - Many thanks! I shall go and experiment, then :) -- Mo McKinlay [EMAIL PROTECTED] - GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Posting to this list without 500 bounces?
> > When I was researching the use of ORBS and MAPS a few weeks > > back, my first thought was that the DUL would unfairly block Linux > > users running Sendmail. Looks like that's true. > > Just give sendmail a smart_host of your ISP's mail server. In theory > I guess this slows thing down, and yes it's a pain, but on the other > hand, it works. Unless your ISP's mailservers are unreliable. In which case, you have problems. Taking the "so, change your ISP" line isn't acceptable, and neither are ISP's mailservers being ORBed themselves. It doesn't discriminate against people using Sendmail on Linux; it discriminates against anybody who runs their own mail server because they MIGHT JUST have more competence than the people who run their ISP's servers. While the original blacklist I agree with and support wholeheartedly, the DUL list a pathetic attempt at reducing spam, and has cost users _FAR_ more time and money in trying to work around it in order to send legitimate mail than could possibly have been saved by preventing the spam that originates from dialup IPs. Instead of doing this, ISPs should start configuring their mail servers properly and close those damned open relays. THAT is who MAPS should be putting pressure on, not the innocent end-users. My serveral cents, Mo [who is now praying that his ISP's mail server has decided to work today :P] -- Mo McKinlay Chief Software Architect inter/open Labs - GnuPG Key: pub 1024D/76A275F9 2000-07-22 Mo McKinlay <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Posting to this list without 500 bounces?
When I was researching the use of ORBS and MAPS a few weeks back, my first thought was that the DUL would unfairly block Linux users running Sendmail. Looks like that's true. Just give sendmail a smart_host of your ISP's mail server. In theory I guess this slows thing down, and yes it's a pain, but on the other hand, it works. Unless your ISP's mailservers are unreliable. In which case, you have problems. Taking the "so, change your ISP" line isn't acceptable, and neither are ISP's mailservers being ORBed themselves. It doesn't discriminate against people using Sendmail on Linux; it discriminates against anybody who runs their own mail server because they MIGHT JUST have more competence than the people who run their ISP's servers. While the original blacklist I agree with and support wholeheartedly, the DUL list a pathetic attempt at reducing spam, and has cost users _FAR_ more time and money in trying to work around it in order to send legitimate mail than could possibly have been saved by preventing the spam that originates from dialup IPs. Instead of doing this, ISPs should start configuring their mail servers properly and close those damned open relays. THAT is who MAPS should be putting pressure on, not the innocent end-users. My serveral cents, Mo [who is now praying that his ISP's mail server has decided to work today :P] -- Mo McKinlay Chief Software Architect inter/open Labs - GnuPG Key: pub 1024D/76A275F9 2000-07-22 Mo McKinlay [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: routing kernel
> I'm looking for good support for both routing as well as NAT. > I heard the 2.0.x is one of the best kernels in terms of > VM management, what might matter considering the router is to > be P75 w/ 16mb ram. I run a trio of 486 DX2/66s each with 16mb ram and 500mb HDs as routers/NAT boxes - I've had no downtime in about 18 months on any of the machines. Each one runs 2.0.36 as RedHat patched it for their 5.2 release (I've never had to recompile the kernel for any of them, so I don't know who much this may vary from stock 2.0.36). HTH, Mo. -- Mo McKinlay Chief Software Architect inter/open Labs - GnuPG Key: pub 1024D/76A275F9 2000-07-22 Mo McKinlay <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [bug] test8-preX crashes X on APM resume >>>Re: [Fwd: Returnedmail: see transcript for details]
> On a side note, is there anyone/anyplace willing to allow relaying for my server? One > by one all the networks around here are falling under the ORBS netblock blacklist and > I'm not going to go through any more expense for myself, company, or LUG when we are > perfectly legitimate, tested clean as a whistle, and fully anti-spam compliant etc. We > shouldn't have to pay because someone else has decided our city has a con artist > somewhere. If you're on a fixed IP, I can relay for you, if that helps. Mo. -- Mo McKinlay Chief Software Architect inter/open Labs - GnuPG Key: pub 1024D/76A275F9 2000-07-22 Mo McKinlay <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [bug] test8-preX crashes X on APM resume Re: [Fwd: Returnedmail: see transcript for details]
On a side note, is there anyone/anyplace willing to allow relaying for my server? One by one all the networks around here are falling under the ORBS netblock blacklist and I'm not going to go through any more expense for myself, company, or LUG when we are perfectly legitimate, tested clean as a whistle, and fully anti-spam compliant etc. We shouldn't have to pay because someone else has decided our city has a con artist somewhere. If you're on a fixed IP, I can relay for you, if that helps. Mo. -- Mo McKinlay Chief Software Architect inter/open Labs - GnuPG Key: pub 1024D/76A275F9 2000-07-22 Mo McKinlay [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
