Also take a look at the p9fs/npfs/v9fs stuff that was recently brought into the kernel main. There is a server for it available that looks interesting. (see http://sourceforge.net/projects/npfs for a place to start)
On Mon, 25 Jun 2012 16:17:17 +0200, Michael Haberler wrote: > Am 25.06.2012 um 15:13 schrieb andy pugh: > >> On 25 June 2012 12:11, Michael Haberler <[email protected]> wrote: >>> I wanted to learn about Fuse (http://fuse.sourceforge.net/) and did >>> a prototype halfs which makes the HAL namespace visible in the Linux >>> filesystem. >>> components functions params pins signals threads >> >> I suspect that I might have been the trigger for this, so probably >> ought to comment. > > well, not quite. > > Poked by your theme I investigated the options for having an > associated char device in an RT component; the hard part is signaling > - without busy wait - between the chardevice (linux kernel land) and > the RT component (rtapi/rtai land) which are pretty much 'ships in > the > night'; this is possible but for the more difficult path > (RT->chardevice signalling) this needs an RTAI function currently not > covered by RTAPI ( rt_pend_linux_srq(), see > > http://git.mah.priv.at/gitweb/kernel-playground.git/blob/0310dd00330a90a995e79993d404947798e241d4:/rt-comp-with-device/rtdev2.c) > >> What I was looking for was a way to access HAL realtime functions >> from >> Userspace. I think this could be part of that solution. > > that path (chardev->RT comp) is easier since the RT comp polls anyway > - either the write, or ioctl dev methods can do this directly in > linux > kernel land, or by queuing a request such that is executed in the RT > context on the next cycle. > > 'Calling a HAL function' directly from the kernel (say a write or > ioctl method) basically would execute an RT function in a non-RT > context; in particular the instance data pointer and timing values > are > missing. Not impossible but to be kept in mind. > > NB - this method assumes RTAI and RTAPI - the device wouldnt work as > a userland HAL component. This might or might not be an issue > (firmware upgrades in a simulator are kindof useless), but at least > it's irregular. > >> Other use-cases: >> Currently BSPI outputs the names of the BSPI instances to dmesg. >> This >> is not particularly convenient. Being able to find them in a file >> tree >> would be neater. > > since this is more like attribute retrieval, I'd guess sysfs would be > the better solution; again, non-sim only but with a driver for real > HW > this is a non-issue as well > > I'm happy to add such an animal to a given RT comp as a proof of > concept, provided someone helps me across the street how to retrieve > which attributes > >> It might make the job of configuration tools such as PNCConf easier, >> especially now that so many of the Mesa cards create their own pin >> names. > > sysfs is real straightforward, but I'd appreciate a suggestion what > makes sense to export > >> The original idea was that one might be able to pipe a firmware file >> directly to a smart-serial remote card from userspace to somewhere >> where kernel space could pick it up and use it. > > there's also a more linuxish way to grind this cat, the kernel > firmware request infrastructure (see e.g. > > http://stackoverflow.com/questions/950107/how-does-linux-kernel-know-where-to-look-for-driver-firmware) > > I agree that doing a UART-over-a-HAL-pin-to-send-files is a wart) > >> If there is no significant overhead I would be tempted to suggest >> that >> it be implemented and then we can see how useful it turns out to be. > > the halfuse thing is a user process, and uses the HAL userland API > (plus some of the private API like halcmd does, but nothing else). In > particular, it doesnt use RTAPI (except logging, but that isnt really > needed). As such it isnt any help with the firmware loading theme. > > -m > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. > Discussions > will include endpoint security, mobile security and the latest in > malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
