From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gateway-1237.mvista.com ([12.44.186.158] helo=hermes.mvista.com) by canuck.infradead.org with esmtp (Exim 4.54 #1 (Red Hat Linux)) id 1ElxcG-0007eK-DR for linux-mtd@lists.infradead.org; Mon, 12 Dec 2005 19:02:02 -0500 Message-ID: <439E0F99.8090008@mvista.com> Date: Mon, 12 Dec 2005 16:02:33 -0800 From: Todd Poynor MIME-Version: 1.0 To: Vitaly Wool References: <438FF22A.2060203@ru.mvista.com> <4390C552.60907@mvista.com> <4393D42C.9040303@ru.mvista.com> In-Reply-To: <4393D42C.9040303@ru.mvista.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: linux-mtd@lists.infradead.org Subject: Re: [PATCH] mtd/utils: sync with MTD ioctl interface rework to get rid of MEMGETOOBSEL/MEMSETOOBSEL List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Vitaly Wool wrote: > Todd Poynor wrote: ... >>> if (writeoob) { >>> /* Read OOB data from input file, exit on failure */ >>> - if ((cnt = read(ifd, oobreadbuf, meminfo.oobsize)) != >>> meminfo.oobsize) { >>> + if ((cnt = read(ifd, oobreadbuf, oobavail)) != oobavail) { >> >> >> This requires the input file to be tailored to the oobavail of a >> specific destination device, reducing the benefit of autoplacement. >> It may be best to continue to pad input files oob data to the full >> oobsize, much like the data portion is handled. > > Well, padding doesn't work in nandwrite if the image to be written > contains OOB data. The idea as I see it is if you are trying to write > the image with OOB data, you should know what you're doing, and that > implies knowledge of the oobavail size. > On the other hand, it might be useful to implement an option for > nandwrite which specifies what OOB data length user supposes (default > will be the oobavail). In order to make it work as above, we'd need a way for users to find out what oobavail their mtd driver uses (in dmesg and/or a util), and an option on all the fs utils to write that number of bytes. A file format that specifies what data and OOB size have been generated would do the trick, if we want to get that fancy about it. Just filling out all 16 or 64 bytes in the input file and truncating to oobavail at nandwrite time seems a lower-cost workaround. -- Todd