make sure some newer FS magic macros are defined

Followup from https://codereview.chromium.org/147513003/

Since linux builds now depend on macros defined in linux/magic.h let's make sure that some of the newer values are set.

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=252279

[Mostyn Bramley-Moore, 2014-02-18 17:40:58]

@awong, Lei Zhang: PTAL.

I think it's less messy to define these values together in a single place rather
than ifdef them out individually in the switch statement below (the
HUGETLBFS_MAGIC + TMPFS_MAGIC case would complicate that).

[Lei Zhang, 2014-02-18 18:59:23]

Curious, what Linux distro are you on where these macros are not defined?

[Mostyn Bramley-Moore, 2014-02-19 03:56:14]

On 2014/02/18 18:59:23, Lei Zhang wrote:
> Curious, what Linux distro are you on where these macros are not defined?

I mostly work with embedded linux, where OEMs update their (often custom built)
platforms less frequently than we would like.  This isn't likely to be much of a
problem on desktop linux distributions.

[Lei Zhang, 2014-02-19 06:21:33]

On 2014/02/19 03:56:14, Mostyn Bramley-Moore wrote:
> On 2014/02/18 18:59:23, Lei Zhang wrote:
> > Curious, what Linux distro are you on where these macros are not defined?
> 
> I mostly work with embedded linux, where OEMs update their (often custom
built)
> platforms less frequently than we would like.  This isn't likely to be much of
a
> problem on desktop linux distributions.

Can I convince you to carry this patch locally? Any supported kernel from within
the last 4 years should have these defined.

Alternatively, let's put a TODO at the top to remove these in a year or two?

[Mostyn Bramley-Moore, 2014-02-19 08:49:01]

On 2014/02/19 06:21:33, Lei Zhang (OOO starting 02-21) wrote:
> Can I convince you to carry this patch locally? Any supported kernel from
within
> the last 4 years should have these defined.
> 
> Alternatively, let's put a TODO at the top to remove these in a year or two?

Added a TODO, but I'm happy to drop this CL if you don't think it would be
useful for other embedded linux targets (I imagine google has enough control
over your own embedded linux targets to not require this.)

Aside: if you have a specified minimum recommended/supported linux kernel
version for chromium, I can use that to try to convince OEMs to upgrade their
kernels.

[Lei Zhang, 2014-02-19 09:18:27]

On 2014/02/19 08:49:01, Mostyn Bramley-Moore wrote:
> On 2014/02/19 06:21:33, Lei Zhang (OOO starting 02-21) wrote:
> > Can I convince you to carry this patch locally? Any supported kernel from
> within
> > the last 4 years should have these defined.
> > 
> > Alternatively, let's put a TODO at the top to remove these in a year or two?
> 
> Added a TODO, but I'm happy to drop this CL if you don't think it would be
> useful for other embedded linux targets (I imagine google has enough control
> over your own embedded linux targets to not require this.)
> 
> Aside: if you have a specified minimum recommended/supported linux kernel
> version for chromium, I can use that to try to convince OEMs to upgrade their
> kernels.

lgtm

Having said that, we don't have a strict policy in place, and there are
workaround of various vintage here and there. IMO, for kernel versions, if there
exists a long-term stable kernel that needs a workaround, that's fine. If it's
within a year or two of EOL, then ok, keep the workarounds for a little longer.
After that, we should seriously consider not supporting workarounds for old,
unsupported kernels.

I have been removing old workarounds as I see them. The only embedded targets we
have are Android and iOS. If I break something that mobile Chromium cares about,
our continuous build usually goes red pretty fast and let me know.

[Mostyn Bramley-Moore, 2014-02-19 10:26:58]

> lgtm
> 
> Having said that, we don't have a strict policy in place, and there are
> workaround of various vintage here and there. IMO, for kernel versions, if
there
> exists a long-term stable kernel that needs a workaround, that's fine. If it's
> within a year or two of EOL, then ok, keep the workarounds for a little
longer.
> After that, we should seriously consider not supporting workarounds for old,
> unsupported kernels.

That sounds like a good rule of thumb for desktop linux.  Embedded targets may
need a slightly bigger window since the cross toolchains have copies of the
kernel headers, and the toolchain's copy isn't necessarily updated when the
kernel for the target is updated.  

> I have been removing old workarounds as I see them. The only embedded targets
we
> have are Android and iOS. If I break something that mobile Chromium cares
about,
> our continuous build usually goes red pretty fast and let me know.

I was thinking of ozone/embedded content shell, which google seems to be
supporting: http://crbug.com/318413

(I'll land this and set a reminder in my calendar to follow up and remove this
about a year from now.)

[Mostyn Bramley-Moore, 2014-02-19 10:27:03]

The CQ bit was checked by mostynb@opera.com

[commit-bot: I haz the power, 2014-02-19 10:27:18]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/mostynb@opera.com/170823002/70001

[commit-bot: I haz the power, 2014-02-19 10:30:23]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-02-19 10:30:23]

Try jobs failed on following builders: mac_chromium_rel

[Mostyn Bramley-Moore, 2014-02-19 10:37:09]

Oops, I thought Lei was an OWNER of this file.

@awong: does this patch look OK to you too?

[Lei Zhang, 2014-02-19 10:55:55]

On 2014/02/19 10:26:58, Mostyn Bramley-Moore wrote:
> > lgtm
> > 
> > Having said that, we don't have a strict policy in place, and there are
> > workaround of various vintage here and there. IMO, for kernel versions, if
> there
> > exists a long-term stable kernel that needs a workaround, that's fine. If
it's
> > within a year or two of EOL, then ok, keep the workarounds for a little
> longer.
> > After that, we should seriously consider not supporting workarounds for old,
> > unsupported kernels.
> 
> That sounds like a good rule of thumb for desktop linux.  Embedded targets may
> need a slightly bigger window since the cross toolchains have copies of the
> kernel headers, and the toolchain's copy isn't necessarily updated when the
> kernel for the target is updated.  

Sure, there's no policy set in stone. We do want to eventually get rid of
workarounds in some reasonable time frame.

> > I have been removing old workarounds as I see them. The only embedded
targets
> we
> > have are Android and iOS. If I break something that mobile Chromium cares
> about,
> > our continuous build usually goes red pretty fast and let me know.
> 
> I was thinking of ozone/embedded content shell, which google seems to be
> supporting: http://crbug.com/318413

I don't know what all the ozone plans are. My advice for you and ozone folks is
to have continuous builds for configurations you care about somewhere. And have
people watching over the continuous builds. When things break, you can react and
discuss what's considered too crufty.

> (I'll land this and set a reminder in my calendar to follow up and remove this
> about a year from now.)

I'm not a base/ owner, so maybe Albert can check the CQ box for you in the
morning.

[awong, 2014-02-20 01:50:27]

LGTM

[awong, 2014-02-20 01:50:44]

The CQ bit was checked by ajwong@chromium.org

[awong, 2014-02-20 01:51:02]

On 2014/02/20 01:50:27, awong wrote:
> LGTM

Checked it for ya...you could have checked it yourself if I had reviewed it
earlier. Sorry about that.

[commit-bot: I haz the power, 2014-02-20 02:05:32]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/mostynb@opera.com/170823002/70001

[commit-bot: I haz the power, 2014-02-20 02:27:33]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-02-20 02:27:34]

Try jobs failed on following builders: linux_chromium_rel, mac_chromium_rel

[Mostyn Bramley-Moore, 2014-02-20 14:32:53]

The CQ bit was checked by mostynb@opera.com

[commit-bot: I haz the power, 2014-02-20 14:33:05]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/mostynb@opera.com/170823002/70001

[commit-bot: I haz the power, 2014-02-20 17:06:10]

Change committed as 252279