<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Mar 14, 2014 at 9:23 AM, Naman Govil <span dir="ltr"><<a href="mailto:namangov@gmail.com" target="_blank">namangov@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class=""><div><br>
</div><div><br></div></div><div><span style="font-family:arial,sans-serif;font-size:13px">I agree with the long term goal, but from the point of view of a project in GSoC, is'nt it better for me to implement the block device API first, and then in the course of time think about the generic device interface? </span><span style="font-family:arial,sans-serif;font-size:13px">  </span></div>

<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px"></span></div></div></blockquote></div><br></div><div class="gmail_extra"><br>
</div><div class="gmail_extra">you should do what you think best. Block device APIs are a much-worked-on problem, as are generic device interfaces. The special needs of firmware make them tricky. I prefer generic because it's too easy to work out a block device interface that won't fit into a generic framework -- that's been done, frequently -- but a well designed generic framework will easily accommodate a block device interface -- see Unix or Plan 9.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">In other words, you can design a special case that makes doing a good design of the general case almost impossible. That's been done too; see UEFI.</div><div class="gmail_extra">
<br></div><div class="gmail_extra">ron</div></div>