can we use dynamic registeration for device drivers when IOCTLs are used??
You do not need a major number to define an ioctl, these are unrelated.
What you do need, is a (somewhat) unique (or at least, not one of the built in) number or letter to identify your ioctl range. These may optionally be registered (with the register being in Documentation/ioctl/ioctl-number.txt, which also has instructions for usage) to prevent (or at least reduce the probability) of others using it as well.
I highly recommend reading the documentation in any case as it explains the common conventions and usage.
Related
I want to understand the differences of LoROM and HiROM cartridges in detail.
On a theoretical level, it is clear to me that any cartridge could do whatever address mapping magic it wants to, e.g. banking to extend the physical address space. For that, there is no need for the SNES itself to know about such mapping (unless it uses a cache, which AFAIK it doesn't). The only limitation is that the cartridge cannot affect any mapping of bus peripherals that are already connected inside the SNES, unless special mechanisms are in place to allow that, such as the cartridge being able to suppress the chip-select for an SNES-internal chip. Again, I don't know of any such mechanism.
I found LoROM and HiROM memory maps here: https://en.wikibooks.org/wiki/Super_NES_Programming/SNES_memory_map#LoROM
Comparing those, the only differences I see are in addresses served by the cartridge, which does not require the SNES itself to know whether a LoROM or HiROM map is used. In particular, it does not seem that the LoROM vs. HiROM distinction causes any address block to be switched between being "in the SNES" vs. being "in the cartridge".
So far, I would have expected that LoROM and HiROM are concepts being used in the design of the cartridges, transparent to the SNES itself.
However, the same article linked above later describes the "internal" SNES header (note: NOT the SMC header, which they suggest to treat as unrealiable information). As far as I understood, the SMC header is external information provided by ROM reader devices, while the internal SNES header is actually stored in the ROM. They do mention that the internal SNES header may appear at different places in the memory map depending on the address mapping, which is obvious. They suggest to "find" the header by probing (for emulation purposes), but it is unclear to me what extent of probing is done by a real SNES.
The internal header contains a field that distinguishes LoROM vs. HiROM. That page seems emulation-oriented and is a little blurry with respect to emulation vs. real hardware, but the key point is that the LoROM vs. HiROM distinction is stored in the actual ROM chip on actual cartridges, to be readable by the SNES.
Given that it seems like LoROM and HiROM could be distinguished in the cartridge alone, transparent to the SNES, what effect does this flag in the header have on the SNES?
The SNES itself does not make use of the "internal" SNES header at all (except for the interrupt vectors, of course). It is purely for informational purposes. Technically, there is no need for the info in that header to be reliable, but in the handful of cases I have personally investigated it appears to be accurate.
So yes, the mapping is all done by the cartridge.
This may help:
The SNES Cartridge, Briefly Explained
It's all in the cart man.
OK then, perhaps this will clear things up.
Although it seems impossible from research:
Passing parameter to xci core
I am designing a custom core which uses an instance of a Xilinx FIFO. However, the top module has parameters which are exposed in the IP Packager, and should modify the included FIFO core.
module top();
parameter C_FIFO_DEPTH = 256
xilinx_fifo_core #(
.FIFO_DEPTH(C_FIFO_DEPTH)
) my_fifo_instance (...);
This way, when someone instantiates my module, by overriding parameter C_FIFO_DEPTH, they also change the embedded FIFO's depth.
Although this would work for user written modules, it doesn't work for instances of IP cores (xci), which seem to be configurable only through the "Customize IP" gui.
I have disabled Out-of-context generation, but still no dice.
I am currently working on a (very messy) solution using tcl scripts in the packaged core, however an elegant solution is desperately needed.
You can do this with the XPM_FIFO_xxx cores. Look in the UG953 Libraries Guide for docs and examples. You can also do it for RAM with XPM_MEMORY_xxx.
I can't think of any elegant solution, but here are three more messy ones:
(1) just use the largest FIFO you'll ever need. (Clearly likely to be a waste of area.)
(2) create a range of FIFOs of different sizes and use generate case to choose the right one. (Only any good if the range of useful sizes is reasonably limited.)
(3) don't use an IP block - design your own FIFO. (You probably thought of that.)
I'm writing new kernel module and I add implement new IOCTL's.
Is there any rule that I should follow with IOCTL's numbering ?
Maybe there is some "user range" ?
I work with kernel 2.6.21 on embedded platform.
IOCTLs are defined to be device dependent -- if there were "standard" ioctls for people to implement, these would be syscalls like read and write.
There are a few conventions for ioctl numbers:
the parameter direction (in, out, both) is encoded in the ioctl number in two bits. This isn't mandatory, unless you use the common copy-from-user/copy-to-user code, which is recommended.
there is a magic number to avoid conflicts. There is no real harm if two devices define the same ioctl, but using different numbers gives an additional opportunity to catch errors.
I'm making a small kernel module to provide user-space access to some kernel-mode only features of an ARMv7 chip (specifically, cache control). I'm reading through Linux Device Drivers by Corbet, Rubini, and Hartman. In it they describe how to make a full driver+device+bus. I don't want to create a bus driver at all. In fact the 'driver' that I'm making doesn't really need to match against a device definition at all - it is implicitly matched to the platform's CPU. Can anyone explain to me:
Where in sysfs should my attributes go? Should it be in my module entry under /sysfs/modules/mymodule? /sys/devices/platform seems promising too, and so does /sys/devices/system/cpu.
If there is an existing place where I should put my kobject/attributes, how do I plug it into it? How do I get the necessary kset? All the examples I've seen create a kset and then link to it from the kobject - I haven't seen an API for requesting an existing named kset?
Sorry if this is just impossibly obvious, or if there's some really straightforward and easily discovered example somewhere that I haven't discovered for some reason. Can anyone shed any light on this?
I haven't worked with sysfs much, but I found a simple-looking example that's pretty similar to what you are doing (naturally, it's also under ARM). Take a look at arch/arm/mach-omap1/pm.c, specifically the idle_show/idle_store sysfs file. It gets registered (using sysfs_create_file()) as /sys/power/sleep_while_idle and uses the global /sys/power kobj (defined in include/linux/kobject.h). There are a few other global kobj's defined there that you could use, although I'm don't think any are a good fit for your driver.
Is this going to be a platform driver? As a driver that doesn't fit under any bus, it seems like a good fit. Platform drivers get their own directory under /sys/devices/platform, and can have attributes there. Take a look at drivers/hwmon/coretemp.c, which has temp1_crit, temp1_crit_alarm, temp1_input, etc. as attributes. It looks fairly simple: create the attributes (maybe with __ATTR()?), list them all in an array, define an attribute_group, register it with sysfs_create_group() in the probe() function, and unregister it with sysfs_remove_group() in the remove() function.
There are probably other platform drivers that define attributes (search for sysfs_create_group) if you need other examples. Hope this helps!
Well, they bring (should bring at least) great increase in performance, isn’t it?
So, I haven’t seen any Linux kernel sources, but ‘d love to ask: are they used somehow? (In this case – there must be some special “code-cap” for system that has no such instructions?)
The SSE and MMX instruction sets have limited value outside of audio/video and gaming work. You might find a few explicit uses in dark corners of the kernel, but I wouldn't count on it. The answer in the general case is "no, they are not used", nor are they used in most non-kernel/userspace applications.
The kernel does sometimes optionally use certain x86 instructions that are specific to certain CPUs (e.g. present on some AMD or Intel models but not all, nor vice-versa), such as syscall, but these are different from the SIMD instruction sets you're referring to, and are not part of some wider set of similarly-themed extensions.
After Mark's answer, I went looking. The only place I could easily identify them being used is in the RAID 6 library (which also has support for AltiVec, which is the PowerPC SIMD instruction set).
(Be wary just grepping the tree, there are a lot of spots where the kernel "knows" about SSE/MMX to support user-space applications, but isn't actually using it. Also a couple cases of unfortunate variable names that have absolutely nothing to do with SSE, e.g. in the SCTP implementation.)
There are severe restrictions on using vector registers and floating point registers in kernel code. See e.g. chapter 6.3 of "Calling conventions for different C++ compilers and operating systems". http://www.agner.org/optimize/#manuals
They are used in the kernel for a few things, such as
Software RAID
Encryption (possibly)
However, I believe it always checks their presence first.
"cpu simd instructions use FPU"
erm, no, not as I understand it. They're in part a modern and (much) more efficient replacement for FPU instructions, but a large part of the SIMD instruction set deals with integer operations.
I've never looked very hard at it, but I suppose (ok, hope) that SIMD code generated by a recent gcc version will not clobber any registers or state.