--- In "charliem_1216" <>
wrote:
>
> Hi Jesse --
>
> Thanks for the insights.
>
> --- In "Jesse Off" <joff@> wrote:
> >
> > > I guess this discussion is in the TS-7000 group since TS
delivers
> > only
> > > a binary object file SD.o for SD card support. Obviously this
is a
> > > stumbling block for those of us who prefer 2.6 kernels.
> >
> > A 2.6 driver could still be made without TS. TS delivers a OS-
>
> How, w/o TS? You mean using TS sdcore.o and sdcard.o in 2.6, or
> without TS modules at all? This seems close to the binary firmware
> blobs that are now in use for many devices (distributed with the
> kernel has hex files or some such). Too bad we can't take that
route
> (can we?).
All someone would have to do is translate the Linux 2.6 block driver
interface to the SD API routines described in sdcore.h and
implemented in sdcore.o. The SD API we present in sdcore.h/sdcore.o
is much simpler than Linux's block driver interface. Use "ld" to
combine the Linux shim .o with TS's sdcore.o and you'll have a 2.6
compatible loadable module.
You could link sdcore.o in the kernel and have the SD driver built-
in, but you might get in trouble from the GPL police. Neither the SD
association (since you don't have the source to sdcore.o) nor TS
would care if you do that though.
>
> > independent gcc or IAR compiled object file sdcore.o that
contains a
> > simple and stable C API to access the SD card. We publish a
>
> What about EABI?
I have the sdcore.c on my computer. I don't have a EABI toolchain
built and handy, but if someone required it for use in a OS port I'm
willing to generate it.
> > especially knowing now that Linux considers backward
compatibility
> > nonsensical.
>
> That's wrong and uncalled for. I think you mis-interpret 'backward
> hardware compatability' with 'stable internal API compatability'.
> Others have explained it much more eloquently that I, but AFAIK:
>
> * Linux has no guarantee of internal, kernel API stability,
> _especially_ across major versions like 2.4 to 2.6. (And with the
> develoment model used now, even within the 2.6 series to a smaller
extent)
>
> * Vendors and developers are encouraged to get their drivers
released
> and included in the kernel. This virtually guarantees long-term
> community HW support, even as internal APIs change. If a kernel
> developer changes an internal API, he also takes on the implied
> responsibility of fixing every driver he breaks.
>
> * Vendors that choose not to work for driver inclusion in main-line
> have extra work to do, and this is true whether the outside modules
> are binary only (ie VMWare, Nvidia), or open (ie, cirrus stagnating
> 2.6 kernel drivers).
>
> The end result is that HW support, once in the mainline kernel,
lasts
> quite a long time.
Thanks for that clarification. I'm sorry if my comments on Linux
offended you or others on this list. I continuously underestimate
the emotional attachment and pride this OS generates amongst its
advocates.
When it comes down to it, I just haven't bought into yet the fact
that 2.6 is significantly better than 2.4. Heck, I still use Windows
98 at home and that computer can still do 99% of the things that
matter to me the same as my more modern Windows XP machine at work
and it'll be probably 2-3 years before I even look at Vista.
//Jesse Off
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|