Microsoft Forefront Server Security forwarded attachment

* Microsoft Forefront Server Security forwarded attachment
@ 2011-02-17 23:16 ForefrontServerSecurity
  0 siblings, 0 replies; 6+ messages in thread
From: ForefrontServerSecurity @ 2011-02-17 23:16 UTC (permalink / raw)
  To: broonie; +Cc: hch, linux-kernel, linux-fsdevel, ryan, akpm

[-- Attachment #1: Type: text/plain, Size: 474 bytes --]

The body from the message "Re: [PATCH 0/10] Add yaffs2 file system:  Fifth patchset", originally sent to you by linux-kernel-owner@vger.kernel.org (linux-kernel-owner@vger.kernel.org), has been forwarded to you from the Microsoft Forefront Server Security Quarantine area.
This message body may have been re-scanned by Microsoft Forefront Server Security and handled according to the appropriate scan job's settings.

<<Body of Message>>

[-- Attachment #2: Body of Message --]
[-- Type: application/octet-stream, Size: 3456 bytes --]

On Thursday 17 February 2011 14:48:08 Mark Brown wrote:
> On Thu, Feb 17, 2011 at 11:12:06AM +1300, Charles Manning wrote:
> > On Wednesday 16 February 2011 21:04:20 Christoph Hellwig wrote:
> > > The procfs interfaces should be replaced by something saner,
> > > the insane amount of ad-hoc tracing crap should be replaced by much
> > > less strategically placed trace events, and all those stupid compile
> > > time options have absolutely no business at all beeing there for a
> > > filesystem -
> >
> > Why not?
> >
> > > remember you can get media from all over the place.
> >
> > No you can't. This is a flash file system for soldered down flash. I
> > think that is a fundamental place where your understanding of what yaffs
> > is falls down.

I'm not sure I really understand what Christoph means by "get media from all 
over the place". I took that to mean he thinks people will pug in random 
flash cards and would need to fiddle with options to make them work. That 
would of course suck badly.

That is obviously not the case for a flash file system used on hard-wired 
flash where the system integrator is in control. Users don't get to fiddle.

>
> Even for embedded systems people do end up wanting to do things like
> using the same kernel on multiple systems which may have different
> hardware configurations (distros and reference boards are the obvious
> examples, but I've worked on systems where multiple generations and
> builds of the product were in active use and similar enough to be
> maintained from the same kernel).  Even with single system kernels
> there's still an issue with things like reference boards where users are
> doing things like picking up a new upstream kernel rather than the
> vendor BSP.

Every one of the "stupid compile time options" is there because someone that 
actually **uses** yaffs wanted it. None are there just for fun. The 
compile-time switches are very limited - mostly just there to set up default 
runtime flags that can be overridden at runtime. Some of them are there to 
work around bugs and limitations in the mtd.

Even with BSPs, there will often be some board tuning to, do things like set 
up the mtd partitions.

Picking up an new kernel is easy, so long as the mtd code has not been broken 
in the interum. 

Last week I dropped the yaffs code into an omap3 build of 2.6.37 with no 
fiddling and with default settings and it "just worked".

>
> > > If you can't encode these difference in your on-disk format it has
> > > absolutely no business going into mainline with this format.
> >
> > Yaffs does not really have an on-disk format like most other fs do.
>
> I'm not sure exactly how you'd do this for a filesystem but this is
> starting to sound a lot like platform data...  Though presumably if the
> data isn't stored on the device currently it'd be a simple matter of
> programming (if wasteful) to add it.

NB flash file system - not file system! Working via mtd is different to 
working via blocks.

Most of the required data is passed through mtd and you don't need any special 
platform data beyond the nand setup in the board tuning file.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

^ permalink raw reply	[flat|nested] 6+ messages in thread