On Sun, 31 Oct 2010 13:29:24 -0700, Patrick Elliott wrote:

> How so? Drivers can be compiled into kernel, but most are not any more,
> and they can be added or removed, without effecting the kernel itself.
> You do have to compile it for the specific processor though, so where
> exactly do you think I contradicted myself?

Looking at the source for the version of Android on my phone, I see the 
drivers in with the kernel source.

My router (which is not Android-based, but Linux based) is the same.  Not 
x86 hardware, but it uses drivers for hardware that is readily available 
on x86 systems, so the drivers are in the kernel tree.

Jim

Post a reply to this message

On Sun, 31 Oct 2010 16:51:29 -0400, Jim Henderson wrote:

> On Sun, 31 Oct 2010 13:29:24 -0700, Patrick Elliott wrote:
> 
>> How so? Drivers can be compiled into kernel, but most are not any more,
>> and they can be added or removed, without effecting the kernel itself.
>> You do have to compile it for the specific processor though, so where
>> exactly do you think I contradicted myself?
> 
> Looking at the source for the version of Android on my phone, I see the
> drivers in with the kernel source.
> 
> My router (which is not Android-based, but Linux based) is the same. 
> Not x86 hardware, but it uses drivers for hardware that is readily
> available on x86 systems, so the drivers are in the kernel tree.

Note that when I do compiles for my router, the drivers are modules, but 
they're still part of the kernel source tree.  Modular or compiled-in 
modules still tend to be in the kernel source tree unless you're talking 
about something like the proprietary NVidia or ATI drivers.

Jim

Post a reply to this message

Jim Henderson wrote:
> Without a doubt.  Windows' roots (starting with NT) was on DEC equipment, 
> after all, not x86.

Heh.  I don't think they took actual VMS code and tried to port it for Windows.

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

Jim Henderson wrote:
> On Sat, 30 Oct 2010 18:54:00 -0700, Patrick Elliott wrote:
> 
>>  As I understand it the kernel may as well be the
>> same, assuming the same processor, but the interfaces, i.e. drivers, to
>> the rest of the stuff, isn't.
> 
> Um, no, actually, the APIs would be the same because it's the same kernel 
> code.

The kernel code (at least, the "same" kernel code) is generally not what 
provides the APIs to device drivers on embedded devices.

> Wait, what?  You seem to be contradicting yourself....

No, he's saying you *could* do it, but generally that isn't what happens. 
People don't port X11 to their cell phone, they use directFB. People don't 
port Pulse to their cell phone, they use whatever API works with the 
hardware. They don't use udev, they just write directly to the USB devices 
they support. Etc.

That the drivers are in the kernel tree on *your* devices doesn't mean 
they're part of the kernel on other devices.

 > unless you're talking
 > about something like the proprietary NVidia or ATI drivers.

Well, unless you're talking about anything that's not generic, really. Does 
the standard Linux kernel have device drivers for CDMA chips? 4" LED 
touchscreens? Power control modules for turning on and off various parts of 
various chips? GSM codec hardware?

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

On Sun, 31 Oct 2010 14:13:59 -0700, Darren New wrote:

> Jim Henderson wrote:
>> Without a doubt.  Windows' roots (starting with NT) was on DEC
>> equipment, after all, not x86.
> 
> Heh.  I don't think they took actual VMS code and tried to port it for
> Windows.

Maybe, maybe not.  I have a vague recollection of a book by Dave Cutler 
(I think it was) who went to MS from DEC and was responsible for the bulk 
of kernel coding in NT.  Probably didn't take DEC code (otherwise DEC 
could've sued him), true.

Jim

Post a reply to this message

On Sun, 31 Oct 2010 14:21:44 -0700, Darren New wrote:

> Jim Henderson wrote:
>> On Sat, 30 Oct 2010 18:54:00 -0700, Patrick Elliott wrote:
>> 
>>>  As I understand it the kernel may as well be the
>>> same, assuming the same processor, but the interfaces, i.e. drivers,
>>> to the rest of the stuff, isn't.
>> 
>> Um, no, actually, the APIs would be the same because it's the same
>> kernel code.
> 
> The kernel code (at least, the "same" kernel code) is generally not what
> provides the APIs to device drivers on embedded devices.

Device drivers talk to the kernel through APIs the kernel provides, 
though.

>> Wait, what?  You seem to be contradicting yourself....
> 
> No, he's saying you *could* do it, but generally that isn't what
> happens. People don't port X11 to their cell phone, they use directFB.
> People don't port Pulse to their cell phone, they use whatever API works
> with the hardware. They don't use udev, they just write directly to the
> USB devices they support. Etc.

DirectFB IIRC is in the kernel...X isn't.  Pulse isn't kernel-level 
stuff, it's middleware.  Sure the middleware isn't the same.

My router's kernel has devpts mounted and uses procfs.  Those are 
provided by the kernel (or by kernel drivers interfacing to the kernel).

> That the drivers are in the kernel tree on *your* devices doesn't mean
> they're part of the kernel on other devices.
> 
>  > unless you're talking
>  > about something like the proprietary NVidia or ATI drivers.
> 
> Well, unless you're talking about anything that's not generic, really.

"something like the [...]" - now does that imply anything other than 
"anything that's not generic"?

> Does the standard Linux kernel have device drivers for CDMA chips? 4"
> LED touchscreens? Power control modules for turning on and off various
> parts of various chips? GSM codec hardware?

Define "standard Linux kernel"?

Jim

Post a reply to this message

Jim Henderson wrote:
> Maybe, maybe not.  I have a vague recollection of a book by Dave Cutler 
> (I think it was) who went to MS from DEC and was responsible for the bulk 
> of kernel coding in NT.  

Yep. But the fact that Cutler came from DEC says nothing about how portable 
the OS he helped write based on his experience was. People give them crap 
for "stealing" VMS, but when you work at that level, your experience is why 
you get hired.

Also, I think the XBox360 runs a version of Windows ported to a PowerPC, so 
I think it's more ambiguous than you might think.

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

On 10/31/2010 1:51 PM, Jim Henderson wrote:
> On Sun, 31 Oct 2010 13:29:24 -0700, Patrick Elliott wrote:
>
>> How so? Drivers can be compiled into kernel, but most are not any more,
>> and they can be added or removed, without effecting the kernel itself.
>> You do have to compile it for the specific processor though, so where
>> exactly do you think I contradicted myself?
>
> Looking at the source for the version of Android on my phone, I see the
> drivers in with the kernel source.
>
> My router (which is not Android-based, but Linux based) is the same.  Not
> x86 hardware, but it uses drivers for hardware that is readily available
> on x86 systems, so the drivers are in the kernel tree.
>
> Jim
Yes, but, as I said, you could add ones you don't have, or remove the 
ones that are there. The kernel needs to know how to talk to the 
hardware, but it doesn't give a crap, beyond the obvious need to run on 
the processor you compiled to, *what* that hardware actually is. That 
was my point. Sure, for stand alone cases, a lot of the drivers are in 
the kernel tree. Same, to an extent, for "some" of the common ones for 
PCs. Doesn't mean they have to be there, beyond the basics needed to get 
something loaded in the first place.

-- 
void main () {
   If Schrödingers_cat is alive or version > 98 {
     if version = "Vista" {
       call slow_by_half();
       call DRM_everything();
     }
     call functional_code();
   }
   else
     call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models, 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

On Mon, 01 Nov 2010 17:45:06 -0700, Patrick Elliott wrote:

> Yes, but, as I said, you could add ones you don't have, or remove the
> ones that are there. The kernel needs to know how to talk to the
> hardware, but it doesn't give a crap, beyond the obvious need to run on
> the processor you compiled to, *what* that hardware actually is.

As software, it *can't* "care".  I don't understand your point at all.

Jim

Post a reply to this message

On 10/28/2010 3:12 PM, Darren New wrote:

> Well, no. There's interrupts, sensors saying how many coins are there,
> to signal when it's out of coins or has been filled incorrectly, timing
> delays for releasing various coins, dealing with power going out and
> coming back on while the mechanism is operating, etc.

Surely a lot of that should be handled by the firmware. How does it 
communicate? RS232/RS485, TCP/IP, USB, CAN, etc?

What data does the device communicate back to the host? What does the 
host send to the device?

Obviously there must be some sort of protocol, and the device's firmware 
probably only communicates the bare minimum to work with the host. If 
you don't have the messages it expects and the messages it sends laid 
out for you, it could be a bit of a challenge. You'll probably miss a 
corner case somewhere. (For example, upon host init, the coin counter 
expects to be sent a certain set of data to initialize properly, or 
perhaps you missed the "coin stuck" message because you never saw it in 
your reverse engineering tests)

> Everything's trivial if you aren't the one writing the code.

Of course!

>> I guess the real question is "why are people manufacturing devices
>> that will only ever be used as part of an embedded system writing
>> drivers for it that won't work as part of an embedded system?"
>
> Except it *is* a driver working as part of an embedded system, obviously.
>

Also, less expensive to support only one embedded OS.

Of course, I wouldn't be surprised that even if the device communicated 
over a common, easily accessible protocol that it's opaque through a set 
of DLL's. I've seen a lot of devices like that when I was working on HMI 
code. Some of the basic sensors are really quite easy to deal with. We 
had a prox sensor whose communication protocol was to raise a single 
line (RTS, I think ...) on the RS232 port as an indicator that something 
was in proximity. Extremely simple to deal with.

-- 
~Mike

Post a reply to this message