On Wednesday 02 July 2008, John Kasunich wrote: > > request_firmware(&fw, firmware, dev); > I tried to find out how this would work. Google found > http://lwn.net/Articles/32997/ which is ancient, but it is the only "in > plain english" explanation of how request_firmware works that I could > find in a quick search. If the current reality is different, please > point me to better docs.
You will find extensive documentation and working examples within the kernel source tree - Exactly the same information I used when last implementing a driver requiring external firmware. > So we need hooks into the hotplug system. More documentation to read, > more code in our drivers, more connections to Linux APIs that have > little or nothing to do with machine control. (I sure hope nobody is > hotplugging machine control components.) The hotplug subsystem provides a number of services, not all are purely for plugging/unplugging "hot" hardware.. But you already have "components" hooking into the USB bus (or the parallel port) - Any one of these devices could disappear whilst the box is live. > > There is only one correct way of doing it. > > An assertion without the reasoning behind it isn't going to convince > anybody. Anybody can assert that their way is the "only one correct way". On Tuesday 01 July 2008, Sebastian Kuzminsky wrote: > 3. It would be nice if users couldn't accidentally re-program their > FPGAs in mid-run, ie if firmware loading happened at the sole > discretion of the driver rather than having multiple pieces of > code twiddling the boards. On Thursday 03 July 2008, Sebastian Kuzminsky wrote: > Programming firmware into a device is totally > device-dependent, and the responsibility of the device driver. > > As you say, all the kernel firmare framework does is let the driver > request a firmware file from userspace by name, and have that firmware > delivered to the driver. It's a very focused "open/read/close" in the > kernel, backed by userspace via the standard uevent/udev infrastructure. Looks like Sebastian has already pointed out why request_firmware is the right way. > > R-I-P is a hangover from the NIST days and contributes much to > > many of the poor decisions inflicted on the user. > That is easy to say for someone who doesn't do EMC2 development Now why do you suppose that is ?? > > Dump the cruft and move on. > > RIP is not cruft until a viable alternative exists. You have asserted that 2.4 series kernels are no longer supported (2.2.xx went out the window when the build system was broken). RTLinux doesn't run on the more recent 2.6 kernels (or any 2.6.x series ?) - So ratpi for RTLinux is a dead end, or put another way, Cruft. Once Sebastian implements firmware loading in kernel space, bfload is redundant. i.e. Cruft. > In my view there are fundamental differences between the Linux driver > model and what EMC2 needs. Maybe we should discuss this - if my view is > in the minority, maybe I need to be convinced to change it. > > My ideal model for all the realtime parts of EMC (not just drivers) > consists of having a minimal amount of interaction with Linux - just > enough to tell Linux "I own this device (memory range, I/O ports, etc), > keep your bloody hands off". The more Linux APIs we use, the more > maintenance we will have to do as those APIs change over the years. Simply by creating a kernel module, you automatically incur the overhead of such wonderfull things as kobjects - To ignore even the most basic of services that the kernel provides is, um, short sighted. > The more I think and write on this subject, the more I feel like I'm > preaching a 1980s or 1990s programming style in the face of the > inexorable march into the 21st century. But it really pains me that > such fundamentally simple tasks as talking to hardware have gotten so > damned complicated. I just want get things set up, and then have the OS > get the hell out of the way. If you want to bury your head in the last century, don't be supprised when tomorrow gives you a quick kick in the knackers as it passes by. On Tuesday 01 July 2008, John Kasunich wrote: > The kernel, udev, and "all that stuff" exist to perform one task - to > make the hardware installed in a computer available to _all_ of the > applications on that computer. There are many layers of abstraction > involved - user programs don't access hard disks, they access > filesystems, which access block devices, which eventually access disks. > The same is true for network protocol stacks, etc. But regardless of > the layers involved, the operating system is managing that hardware for > the benefit of the _entire_ computer and _all_ of its applications. Up to a point - Some devices only allow a single process at a time to access a particular piece of hardware. For example, when lpd is sending a file to the printer, ppdev is prevented from accessing the same port. > EMC is different, or at least I think it is. For machine control > purposes, I think of the PC as a very powerful and fast embedded > controller, with a really nice and convenient development system (called > Linux) attached to it. Update: GNU/Linux is a multitasking, multithreaded operating system used on a variety of processors such as ARM, PowerPC, as well as Intel's i386 architecture. This also includes multiple processor systems as well as dedicated SoC chips. As a consequence, you really must consider ... Oh never mind. > The hardware that EMC is using is dedicated to > that machine control task and is NOT shared with the operating system or > the rest of the computer. ... and quietly ignores the internals exposed through the /proc entries as well as the shared memory blocks... --- Paul. ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
