On 04/27/2011 04:31 AM, Russell King - ARM Linux wrote: > On Fri, Apr 22, 2011 at 11:53:50AM -0500, Rob Landley wrote: >> --- /dev/null 2011-04-17 13:05:54.917669002 -0500 >> +++ linux/Documentation/arch/00-INDEX 2011-04-22 11:49:26.138917399 -0500 >> @@ -0,0 +1,35 @@ >> +Hardware architectures supported by the Linux kernel. >> + >> +powerpc s390 sh sparc x86 > > What's this here for? The second line is leftover debris from when I was assembling the list, my bad. >> + >> +00-INDEX/ >> + - this file. > > 00-INDEX isn't a directory, so shouldn't have a / suffix. Agreed. :) >> +arm/ >> + - ARM architecture, from http://arm.com > > 1. URLs should end in a / if they're refering to a directory (in this case > the root of the web tree). You're implying that people pulling up google should end it in a slash. That's not generally how the web is used... A webserver can do weird redirects and cgi. There's no way to know from a URL _what_ resource it's referring to, and pretending you do is silly. In this case, the following resolves: http://arm.com/index.php/ Which means that A) it's not a "directory", it's invoking a PHP program, B) the web server happily accepts a trailing slash on the name of the PHP program because it's _always_ stripping the trailing slash before trying to resolve names. The only time I've ever seen the trailing slash matter on a web page is when people write URL redirect scripts and include the slash as part of their regex, which means that yes there have occasionally been pages that are 404 without the trailing slash and resolve fine with it, but it's a _bug_ when that happens, because somebody wrote a broken regex. That is not the case here. Web servers simply don't distinguish between resource types the way you're trying to. In 00-INDEX we're distinguishing directories because as a local resource stored in a filesystem you have to view them differently with standard unix tools: one is a container for multiple different files requiring further selection before viewing, versus a file you examine directly. But when I use a URL to get a web page, the same operation views each URL. There's no "cat doesn't work on this one, you need to ls -l" UI difference, the "U" stands for Universal for a reason. Just point your browser and it gives you the page. Ending with a slash is an utterly meaningless distinction in this context. > 2. http://www.arm.com/ is for the CPU architecture only not the contained > platform architectures (eg, shmobile). In this respect, ARM is not like > any other "architecture" listed below. Intel doesn't make motherboards either. (There is an entity ultimately responsible for the arm design, the URL was an attempt to indicate that entity.) I can remove the URL entirely and just assume people know what an arm is if you prefer. (I lean towards stripping contested data off the summaries because the directory is supposed to contain the details. If it doesn't, that's a problem with the directory contents, not with the summary.) > So a better description would be: > - ARM CPU architecture, http://www.arm.com/ So you _want_ to label the directory as "CPU" even though it contains platform SOC stuff? You prefer the directory to be intentionally mislabled because the "what is this" URL only covers a subset of what the directory does? Putting the www back on the URL is an old debate: http://www.codinghorror.com/blog/2008/04/the-great-dub-dub-dub-debate.html Personally, I'm an embedded developer. I tend to remove things that clearly aren't necessary. (Not removing the word "architecture" was my fault when I cut and pasted the original line and trimmed it down. It's the "arch" directory with an ID line at the top of the file saying that these are hardware architectures. Indentifying each one that way is like saying "Linux support for" at the start of each line.) > Lastly, I'm not entirely convinced about moving this stuff. I've not > seen anything which explains why this is being done or what benefit it > is supposedly bringing. Does the same logic apply to the "arch" directory in actual source code? All those subdirectories under it _could_ be at the top level. For that matter, "filesystems" could all be at the top level too. It's cluttered, so I'm trying to collate. The Documentation directory is a mess right now. A lot of the information it contains is specific to a given hardware platform, which probably isn't of interest to people who aren't using that hardware platform. There's plenty of documentation that's _not_ target-specific, so collecting together the stuff that IS target-specific seems like an obvious cleanup to me. Is your objection that Documentation isn't cluttered enough to warrant cleanup? Or that mirroring "arch" a level up is a surprising cleanup to make? Rob -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
