Kernel News

Renaming SMB

Steve French of Microsoft posted a bunch of patches to the SMB/CIFS filesystem, sparking an interesting little discussion. For starters, Linus Torvalds merged the patch set within a day but also had some remarks:

"You pretty much interchangeably use 'cifs' or 'smb3' for the filesystem, as shown once more by the commit messages here (but also the subject line).

"The filesystem directory is called 'cifs', and I've taken to use that in my 'Pull cifs updates' thing from you to just avoiding the confusion.

"And now we have ksmbd (yup, I just merged that pull request too), so we have a 'cifs client' and a 'smb server'. Aaarrgh.

"I understand that some people may care about the name, may care about 'smb2 vs smb3', or whatever. But I have to admit finding it a bit annoying how the code and the directory layout uses these different terms pretty much randomly with no real apparent logic.

"Somehow the NFS people had no problem completely changing everything about their protocols and then still calling the end result 'nfs client' vs 'nfs server'.

"Oh well. I'm assuming it's not going to change, and it's not really a problem, I just wanted to mention my frustration about how clear as mud the naming is."

Steve had a very interesting and seemingly a very honest reply. He said, "I (and many at Microsoft and in Samba team etc.) also have a strong desire to stop using the word 'CIFS' as it has been associated with some very high profile attacks, and with the introduction of SMB2.1 support (which was far more secure) in 2009 no one should be using the very old CIFS dialect (aka 'SMB1' dialect). So if you are ok with renaming the client dir and module name – we can gradually stop using the word/name 'cifs' except for the parts of code which really are needed to access the (unfortunately hundreds of millions of) very old devices which require SMB1 ('CIFS')."

Steve added:

"Note that with the introduction of various security features in SMB3 (then even more security features in SMB3.1.1) it seems like it seemed confusing to users to tell them 'mount -t cifs …' which was why I added support for 'mount -t smb3' (to cifs.ko) in the 4.18 kernel/ but I also would strongly like to stop using the word 'cifs' in module name going forward, even if it does cause a little bit of extra work for distros (most of which could be handled in the mount helper in any case)

"If no objections, we can start moving most things on the client to 'smb.ko' rather than 'cifs.ko' …

"Do you have any objections to me renaming the client's source directory to 'fs/smb3' (or fs/smb) and fs/smb3_common …?"

Linus replied, "I'm ok with directory renames, git handles it all well enough that the pain should be fairly minimal. I'd ask for that to be done during a fairly calm cycle, though, when there isn't a lot pending, so that any rename conflicts will be minimized."

But he also added:

"I'm not entirely enamoured with the name 'smb' as a module (or directory) name, to put it lightly.

"Part of it is that it can mean 'system management bus' too, although in the kernel we happily universally (?) use 'smbus' for that.

"But a big part of it is exactly the history of random different names, which means that I'd like any new name to be more explicit than a TLA that has been mis-used for so long.

"So yes, we have 'fs/nfs/', but I'd rather _not_ have 'fs/smb/'.

"They may superficially look entirely equivalent – but one of them has had a consistent name that is unambiguous and has no horrible naming history. The other has not."

And in terms of what the new name might actually be, Linus went on:

"I'll throw out two suggestions, but they are just that: (a) 'smbfs' or (b) 'smb-client'.

"I think 'smbfs' has the nice property of making it clear that this is just the filesystem part of the smb protocols – that otherwise cover a lot of other things too (at least historically printers, although I have no idea how true that is any more).

"And 'smb-client' as a name is in no way great, but at least it's not just a TLA, and from a naming standpoint it would match the 'smb-common' thing (although I guess you used an underscore, not a dash).

"Again – those are just two random suggestions, and I'm not married to either of them, I just really don't like just that 'smb' because of all the historical naming baggage.

"So if we rename, we should rename it to something new and slightly more specific than what we used to have."

Steve replied, "That should be easy enough (IIRC FreeBSD called their module 'smbfs'), but presumably wait until 5.16 or 5.17 to lessen merge conflicts etc." And he said he'd bounce the idea around with the people on the Samba team and others.

However, after a couple of weeks of behind-the-scenes reflection, Steve reported that there was an ancient fs/smbfs directory already in the Git repository, which he felt might cause enough confusion to not be worth it. So his new suggestion was to use fs/smbfs-client as the new directory name.

But the discussion ended there.

One of the fascinating things about this exchange is the forthrightness of Microsoft talking about public perception as a justification for making a change to the Linux kernel. Once upon a time, the conversation was what the kernel developers would do in response to Microsoft's inevitable attempts to utterly destroy the project. Now Microsoft is admitting a public-perception weakness and seeking solutions with the Linux developers in a collaborative way. And the Linux developers are taking it in stride and collaborating in turn.

Meanwhile, Linus's consideration of alternative names for the SMB filesystem is also interesting, in particular the distinction between fs/smb and fs/nfs, where they seem perfectly complementary, but one is acceptable for historical reasons while the other is not.

It's also generally interesting whenever Linus makes a point of saying that whatever idea he's putting forward is not a "command." A lot of people below the level of his trusted lieutenants, just out of admiration and gratitude, would tend to consider Linus's preferences to be equivalent to being carved in stone. So he's had to (I would imagine) consciously remember to verbalize when he is only talking about something and not making a decision about it.

Testing Standards

Rae Moar from Google proposed a draft specification for Kernel Test Anything Protocol (KTAP) based on Test Anything Protocol (TAP), which was originally designed for the Perl interpreted language in the late 1980s and has since been extended for lots of other languages.

In fact, the extensions are why Rae wanted to set up a kernel-specific version of TAP. He felt there were too many conflicting elements to the TAP spec these days.

He based this new work on an earlier specification (also called KTAP) that had been written by Tim Bird and proposed to the Linux kernel mailing list in June 2020. Tim's original motivation had been to accommodate the various ways that kselftest had come to deviate from the original TAP spec. At the time, Tim's work received some significant interest.

Now, Rae felt that not just kselftest but also KUnit and other kernel testing frameworks needed an update to Tim's attempt – partly because Tim's concept included the idea of nested tests, and some newer tests had started to implement nested tests differently than Tim's conception.

Rae summarized the differences between the original TAP (now at version 14), versus his proposed KTAP specification.

First, he wanted to exclude YAML and JSON from diagnostic messages.

He also wanted to exclude TODO directives, which are really only used to alert whoever's running the tests that a particular test should be implemented at some point. Anyway, there's a SKIP directive that can be used for a similar purpose.

Rae also wanted to be able to nest an arbitrary number of tests – like Tim, he called them subtests.

Brendan Higgins was very enthusiastic about this new KTAP specification. He said, "I would definitely like to see us moving forward with standardizing fully on the KTAP spec."

Kees Cook was also very interested, saying, "thanks for looking at this again! Please understand that while I may be coming across as rather negative here, I would like to have a rational and documented specification for the kernel's test output, too. My main objection here is that we already _have_ a specification, and it's already being parsed by machines, so making changes without strong justification is going to be met with resistance."

Kees pointed out that kselftest was the biggest tester in the kernel and already had the standardized KTAP proposed by Tim the year before. So he said, "I would want buy-in from at least those responsible." He also remarked:

"The fundamental purpose of the kernel's TAP is to have many independent tests runnable and parseable, specifically without any embedded framework knowledge (or, even, any knowledge of TAP).

"The tests run by kselftest come from 2 different TAP-producing harnesses (kselftest.h for C, kselftest/runner.sh for TAP-agnostic tests) as well as several hand-rolled instances in Shell, Python, and C. There used to be more, but I have been steadily fixing their syntax and merging separate implementations for a while now."

But in terms of naming, Kees said he preferred to say "nested tests" rather than "subtests." And he commented extensively on many of the other aspects of Rae's spec.

Meanwhile Rae was taken aback to hear Kees say there was already a spec in use. That was news to him, and he asked for a link. He said:

"Wait, what?! An implementation is not a specification. I thought Tim's attempt at standardizing the TAP that exists under kselftest, KUnit, and elsewhere was recognized as important or at least worthwhile.

"The problem that was recognized, as I understand, was that there are multiple 'interpretations' of TAP floating around the kernel and that goes against the original point of trying to standardize around TAP.

"I know KUnit's usage is pretty minor in comparison to kselftest, but people do use it and there is no point in us, KUnit, purporting to use TAP and remain compatible with any particular version of it if it is incompatible with kselftest's TAP.

"Additionally, there is no way that we are going to be able to stay on a compatible implementation of TAP unless we specify what TAP is separate from the implementation."

Tim also joined the discussion, not necessarily arguing in favor of his earlier draft but certainly with many technical comments on Rae's new version.

Essentially all three engaged in collaborative discussion, each apparently hopeful that the final version would be good and useful. In fact, they each had so much to say that it seems they will very quickly light upon a common vision for this testing framework.

At one point David Gow from Google summed up the situation:

"I think many of the issues here stem from the original TAP spec having been insufficient for kernel stuff, and a bit of divergent evolution having occurred between kselftest, KUnit, and the dormant TAP 14 spec. This proposed spec does approach things more from the KUnit side, just because that's what we're more familiar with, but I agree that kselftest and LAVA are the bigger fish in this pond. KUnit's parser has also been a bit stricter in what it accepts, and the TAP producing code is shared between all of the KUnit tests, which makes prototyping changes a bit easier.

"Fortunately, most of these differences seem pretty minor in the grand scheme of things, so I'm sure we can adapt this spec to fit what kselftest is doing better, while still leaving enough of the structure the KUnit tooling requires."

At one point, Rae pronounced, "Thank you for all of your comments! I am glad to see some discussion on this email. First of all, my primary goal with this email is to advocate for a documented specification for the kernel's test output. I presented my first email largely from the perspective of KUnit and thus, I am not surprised there are points of contention in the proposed specification."

And the discussion continued, largely on technical lines, with everyone clearly aligned on the need to accommodate each other.

One interesting aspect of Linux development is how frequently the developers – or Linus Torvalds – will decide that an existing standard is broken or not useful and simply extend it to suit the kernel. They even forked the C library itself long ago and disagreed with the POSIX standard on the nature of threading. They feuded with the GNU C Compiler developers for years, refusing to upgrade from an increasingly out-of-date compiler version. And Linus resisted using version control for many years, as teams around the world struggled to accommodate his requirements, until finally he first used a proprietary system, to everyone's chagrin, and then wrote his own system that ultimately replaced all the others.