On Thu, May 11, 2006 at 12:15:10AM -0700, Andrew Morton wrote:
>
> The patch titled
>
> deprecate smbfs in favour of cifs
>
> has been added to the -mm tree. Its filename is
>
> deprecate-smbfs-in-favour-of-cifs.patch
>
> See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
> out what to do about this
>
>
> From: Andrew Morton <[email protected]>
>
> smbfs is a bit buggy and has no maintainer. Change it to shout at the user on
> the first five mount attempts - tell them to switch to CIFS.
>
> Come November we'll mark it BROKEN and see what happens.
For Fedora Core 5, I disabled SMBFS for pretty much the same reasons.
Users migrating to CIFS haven't really had any problems so far, except for
this case: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186914
(Which has also come up a few times on Fedora mailing lists since).
I mailed Steve about this, and he did reply, but I can't seem to find it
right now
Dave
--
http://www.codemonkey.org.uk
> > The patch titled
> >
> > deprecate smbfs in favour of cifs
> >
> > has been added to the -mm tree. Its filename is
> >
> > deprecate-smbfs-in-favour-of-cifs.patch
> >
> > See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
> > out what to do about this
> >
> >
> > From: Andrew Morton <[email protected]>
> >
> > smbfs is a bit buggy and has no maintainer. Change it to shout at the user on
> > the first five mount attempts - tell them to switch to CIFS.
> >
> > Come November we'll mark it BROKEN and see what happens.
Sorry for falling in late but we can't do that.
Win 98 (95 too?) shared can not be mounted with CIFS, it requires SMBFS.
Furthermore, there seems to be a strange CIFS error when trying to do so
(varying error codes)...:
13:11 shanghai:/etc # mount //wideland/hda1 /mnt/wideland -t smbfs -o password=realw
13:11 shanghai:/etc # ls /mnt/wideland
. cygwin DRVSPACE.BIN msdos.sys
.. tcpp IO.SYS system.1st
DA windows SCANDISK.LOG tools.conf
Eigene Dateien AUTOEXEC.BAT SETUPXLG.TXT
Programme COMMAND.COM Verkn?pfung mit Scandisk.log.lnk
RECYCLED CYGWIN_SYSLOG.TXT config.sys
13:11 shanghai:/etc # umount /mnt/wideland
13:11 shanghai:/etc # mount //wideland/hda1 /mnt/wideland -t cifs -o password=realw
mount error 2 = No such file or directory
Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)
13:11 shanghai:/etc # mount //wideland/hda1 /mnt/wideland -t cifs -o password=realw
mount error 112 = Host is down
Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)
It's certainly not down.
Jan Engelhardt
--
On Fri, 12 May 2006 17:03:56 +0200 (MEST), Jan Engelhardt
<[email protected]> wrote:
>> > smbfs is a bit buggy and has no maintainer. Change it to shout at the user on
>> > the first five mount attempts - tell them to switch to CIFS.
>> > Come November we'll mark it BROKEN and see what happens.
>Sorry for falling in late but we can't do that.
>Win 98 (95 too?) shared can not be mounted with CIFS, it requires SMBFS.
W98? He's dead, Jim.
On Fri, 12 May 2006, John Kelly wrote:
> On Fri, 12 May 2006 17:03:56 +0200 (MEST), Jan Engelhardt
> <[email protected]> wrote:
>
> >> > smbfs is a bit buggy and has no maintainer. Change it to shout at the user on
> >> > the first five mount attempts - tell them to switch to CIFS.
>
> >> > Come November we'll mark it BROKEN and see what happens.
>
> >Sorry for falling in late but we can't do that.
> >Win 98 (95 too?) shared can not be mounted with CIFS, it requires SMBFS.
>
> W98? He's dead, Jim.
>
huh, my wife has a laptop that she still uses that has w98 on it. And I do
use smbfs to sometimes communicate with it. Why upgrade when you don't
have to?
-- Steve
On Fri, 12 May 2006 12:24:40 -0400 (EDT), Steven Rostedt
<[email protected]> wrote:
>> >Sorry for falling in late but we can't do that.
>> >Win 98 (95 too?) shared can not be mounted with CIFS, it requires SMBFS.
>> W98? He's dead, Jim.
>huh, my wife has a laptop that she still uses that has w98 on it. And I do
>use smbfs to sometimes communicate with it.
Users who need vintage features can use vintage kernels. They haven't
been pulled off the market.
>Why upgrade when you don't have to?
Why drag around old worn out baggage in new kernels?
On Fri, May 12, 2006 at 12:31:02PM -0400, John Kelly wrote:
> On Fri, 12 May 2006 12:24:40 -0400 (EDT), Steven Rostedt
> <[email protected]> wrote:
>
> >> >Sorry for falling in late but we can't do that.
> >> >Win 98 (95 too?) shared can not be mounted with CIFS, it requires SMBFS.
>
> >> W98? He's dead, Jim.
>
> >huh, my wife has a laptop that she still uses that has w98 on it. And I do
> >use smbfs to sometimes communicate with it.
>
> Users who need vintage features can use vintage kernels. They haven't
> been pulled off the market.
Having a shiny new storage box in my house that just might need to talk
with old laptops and new laptops and so on doesn't exactly jive with
that.
Of course perhaps this will cause someone who does care about smbfs to
setup up to the plate and maintain it.
--
Tom Rini
John, on LKML it is expected to not strip CC lists and at least keep the
one you are responding to.
On Fri, 12 May 2006, Tom Rini wrote:
>
> Of course perhaps this will cause someone who does care about smbfs to
> setup up to the plate and maintain it.
>
I admit, I only communicate to that laptop about once a year. But if need
be, I'll (shudder) try to maintain it.
-- Steve
El Fri, 12 May 2006 12:19:18 -0400,
John Kelly <[email protected]> escribi?:
> W98? He's dead, Jim.
Agreed - Win 98 and Me support stops on July 11. If even Microsoft
stops supporting it...
On Fri, 12 May 2006, John Kelly wrote:
> On Fri, 12 May 2006 12:24:40 -0400 (EDT), Steven Rostedt
> <[email protected]> wrote:
>
> >> >Sorry for falling in late but we can't do that.
> >> >Win 98 (95 too?) shared can not be mounted with CIFS, it requires SMBFS.
>
> >> W98? He's dead, Jim.
>
> >huh, my wife has a laptop that she still uses that has w98 on it. And I do
> >use smbfs to sometimes communicate with it.
>
> Users who need vintage features can use vintage kernels. They haven't
> been pulled off the market.
I need to have the latest on my desktop. The machine I'm communicating
with is old.
>
>
> >Why upgrade when you don't have to?
>
> Why drag around old worn out baggage in new kernels?
>
Because it's still used by new kernels.
-- Steve
On Fri, 12 May 2006 09:40:34 -0700, Tom Rini
<[email protected]> wrote:
>On Fri, May 12, 2006 at 12:31:02PM -0400, John Kelly wrote:
>> On Fri, 12 May 2006 12:24:40 -0400 (EDT), Steven Rostedt
>> <[email protected]> wrote:
>> >> >Sorry for falling in late but we can't do that.
>> >> >Win 98 (95 too?) shared can not be mounted with CIFS, it requires SMBFS.
>> >> W98? He's dead, Jim.
>> >huh, my wife has a laptop that she still uses that has w98 on it. And I do
>> >use smbfs to sometimes communicate with it.
>> Users who need vintage features can use vintage kernels. They haven't
>> been pulled off the market.
>Having a shiny new storage box in my house that just might need to talk
>with old laptops and new laptops and so on doesn't exactly jive with
>that.
If every hypothetical user has to die off before old features are
culled from the kernel, it will become a mountain of old stinking
garbage.
>Of course perhaps this will cause someone who does care about smbfs to
>setup up to the plate and maintain it.
Then let them maintain it out of tree. People have to maintain new
features out of tree, why not old too?
On Fri, 12 May 2006, John Kelly wrote:
>
> Users who need vintage features can use vintage kernels. They haven't
> been pulled off the market.
I disagree.
We have two cases:
- newer kernels don't always support vintage hardware any more. We don't,
for example, boot on 1MB PCs (I _think_ we used to), and quite frankly,
if you have 4MB, I'd be surprised it worked either (and that definitely
used to work a long time ago).
Similarly, we've occsionally dropped a driver just because it wasn't
getting maintained, and we knew it couldn't work in the state it was
in. So over the years, machines have stopped being supported (that
said, if somebody complains, we try to re-instate the driver. Most
dropped drivers have never even been commented upon, because they
really aren't used any more. When was the last time you saw an MCA
machine or a PC98? I bet some people on this list have never even
heard of either)
- we sometimes drop sw features that have been deprecated long ago, and
that there are better alternatives for. That said, this is pretty damn
rare too. I can remember Xiafs, and devfs is obviously on that path
too.
But we do _not_ drop features just because they are deemed "unnecessary".
As long as somebody actually _uses_ smbfs, and as long as those users are
willing to test and perhaps send in patches for when/if it breaks, we
should not drop it.
The cost of keeping a filesystem is not normally very high. The way
filesystems in particular get deprecated is if they have really serious
problems, and nobody ends up being able or willing to fix them at all, and
you _can_ migrate away. But if we're talking about win98, it probably
still actually has a pretty big user base, and most of the machines that
run it probably really cannot upgrade.
For exactly the same reason you mention:
"Users who need vintage features can use vintage kernels."
ie you end up having people who have vintage hardware, and they use
vintage kernels, but in their case, the "vintage" is Win95 or Win98. That
does't mean that the _linux_ machine they use is necessarily vintage.
Linus
On Fri, 12 May 2006 09:59:11 -0700 (PDT), Linus Torvalds
<[email protected]> wrote:
>On Fri, 12 May 2006, John Kelly wrote:
>> Users who need vintage features can use vintage kernels. They haven't
>> been pulled off the market.
>I disagree.
What can I say? You're the man. I think you maintain a great kernel,
btw.
I just think forward progress would be easier without dragging around
some of the old baggage in the kernel.
On Fri, 12 May 2006, John Kelly wrote:
>
> I just think forward progress would be easier without dragging around
> some of the old baggage in the kernel.
I think that is generally true, but we've actually been pretty successful
in having a modular enough source tree that most of the time, old code
simply is old - and doesn't much affect new code.
That is especially true in filesystems. We've had a few fairly painful
times (the page cache changes in 2.3.x and the switch to the dentry cache
in 2.1.x(?)), but on the whole we've had a pretty stable VFS interface
that hasn't needed _that_ much work for individual filesystems.
We've had much bigger problems with drivers, although there the main
reason for the problems is just that if some interface changes even very
trivially, there's just so _many_ drivers that they tend to be harder to
fix up (and they tend to do things that you can't "think about" because
it's very much due to bugs or specific issues with some random piece of
hardware that most developers don't even have access to).
Also, while it can be easier in _one_sense_ to move forwards if you drop
the old stuff, it often ends up making it harder in another sense: it can
mean, for example, that people or distributions need to do more work to
update, which in turn can mean that you have a much harder time getting
the change tested.
Which then in turn can mean that you actually lose more developer time
than you gained from the code simplification..
So it's not always a very clear-cut thing. For the _users_ (and those are
who matter most), backwards compatibility is almost always absolutely the
biggest priority, and everything else comes second.
Linus
Linus Torvalds wrote:
>On Fri, 12 May 2006, John Kelly wrote:
>
>
>>Users who need vintage features can use vintage kernels. They haven't
>>been pulled off the market.
>>
>>
>
>I disagree.
>
>We have two cases:
>
> - newer kernels don't always support vintage hardware any more. We don't,
> for example, boot on 1MB PCs (I _think_ we used to), and quite frankly,
> if you have 4MB, I'd be surprised it worked either (and that definitely
> used to work a long time ago).
>
> Similarly, we've occsionally dropped a driver just because it wasn't
> getting maintained, and we knew it couldn't work in the state it was
> in. So over the years, machines have stopped being supported (that
> said, if somebody complains, we try to re-instate the driver. Most
> dropped drivers have never even been commented upon, because they
> really aren't used any more. When was the last time you saw an MCA
> machine or a PC98? I bet some people on this list have never even
> heard of either)
>
> - we sometimes drop sw features that have been deprecated long ago, and
> that there are better alternatives for. That said, this is pretty damn
> rare too. I can remember Xiafs, and devfs is obviously on that path
> too.
>
>But we do _not_ drop features just because they are deemed "unnecessary".
>As long as somebody actually _uses_ smbfs, and as long as those users are
>willing to test and perhaps send in patches for when/if it breaks, we
>should not drop it.
>
>The cost of keeping a filesystem is not normally very high. The way
>filesystems in particular get deprecated is if they have really serious
>problems, and nobody ends up being able or willing to fix them at all, and
>you _can_ migrate away. But if we're talking about win98, it probably
>still actually has a pretty big user base, and most of the machines that
>run it probably really cannot upgrade.
>
>For exactly the same reason you mention:
>
> "Users who need vintage features can use vintage kernels."
>
>ie you end up having people who have vintage hardware, and they use
>vintage kernels, but in their case, the "vintage" is Win95 or Win98. That
>does't mean that the _linux_ machine they use is necessarily vintage.
>
> Linus
>
>
>
Correct call. SMBFS is also very stable and well tested.
Jeff
>
>Why drag around old worn out baggage in new kernels?
>
Maybe merge smbfs into cifs if the protocols are not too different?
Jan Engelhardt
--
>
>
>>Why drag around old worn out baggage in new kernels?
>>
>>
>>
If we follow this logic, then.
"LKML == Wikipedia"
"Your contributions can be reverted and removed at any time by any editor."
So why contribute in the first place?
Leave smbfs. The author worked his butt off and contributed to Linux
with some very useful technology,
and leave his name in contributors.
Jeff
Linus Torvalds <[email protected]> wrote:
>
> The cost of keeping a filesystem is not normally very high. The way
> filesystems in particular get deprecated is if they have really serious
> problems, and nobody ends up being able or willing to fix them at all, and
> you _can_ migrate away.
That's the case with smbfs and cifs, soon.
> But if we're talking about win98, it probably
> still actually has a pretty big user base, and most of the machines that
> run it probably really cannot upgrade.
cifs doesn't support w98 and w95 properly yet. Steve's working on
it, and we hope to have that in place for 2.6.18.
So at this stage, 2.6.18 still appears to be a good time to start pushing
people toward cifs, and December looks like an appropriate time to mark
smbfs as broken. Subject to, of course, feedback-from-the-field.
On Sat, May 13, 2006 at 08:11:44PM -0700, Andrew Morton wrote:
> So at this stage, 2.6.18 still appears to be a good time to start pushing
> people toward cifs, and December looks like an appropriate time to mark
> smbfs as broken. Subject to, of course, feedback-from-the-field.
I'm surprised that other vendors are actually still shipping it[1].
(Not only that, some vendors have actually been sitting on smbfs
patches for well over a year).
Given that it's clearly abandoned, moving to cifs seems to be the
only sensible thing to do, and anything that can be done to ease
that transition should be done.
Dave
[1] Especially after the recent security problem where smbfs stayed
vulnerable for a week or so after CIFS got fixed. How many bad guys
thought "Hmm, wonder if smbfs has the same bug" in that week?
--
http://www.codemonkey.org.uk
grundig wrote:
>El Fri, 12 May 2006 12:19:18 -0400,
>John Kelly <[email protected]> escribió:
>
>
>
>>W98? He's dead, Jim.
>>
>>
>
>Agreed - Win 98 and Me support stops on July 11. If even Microsoft
>stops supporting it...
>
... then people runs more linux in order to get our superior support. ;-)
Helge Hafting