| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Change all 'filename' to 'ptr[in, filename]' and don't imply pointer indirection for filename type.
This is necessary because in some bases we want to embed filename directly into a struct (e.g. unix sock addr).
Similar change was already done for string type for similar reasons. Generally, we want to imply as less as possible.
NOTE: IF YOU HAVE PRIVATE DESCRIPTIONS, YOU NEED TO DO THE SAME REPLACEMENT.
|
| | |
|
| |
|
|
|
|
| |
Currently to add a new resource one needs to modify multiple source files,
which complicates descirption of new system calls.
Move resource descriptions from source code to text desciptions.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This splits generation process into two phases:
1. Extract values of constants from linux kernel sources.
2. Generate Go code.
Constant values are checked in.
The advantage is that the second phase is now completely independent
from linux source files, kernel version, presence of headers for
particular drivers, etc. This allows to change what Go code we generate
any time without access to all kernel headers (which in future won't be
limited to only upstream headers).
Constant extraction process does require proper kernel sources,
but this can be done only once by the person who added the driver
and has access to the required sources. Then the constant values
are checked in for others to use.
Consant extraction process is per-file/per-arch. That is,
if I am adding a driver that is not present upstream and that
works only on a single arch, I will check in constants only for
that driver and for that arch.
|
| |
|
|
|
|
|
|
| |
This solves several problems:
- host usually have outdates headers, so previously we need to define missing consts
- host may not have some headers at all
- generation depends on linux distribution and version
- some of the consts cannot be defined at all (e.g. ioctls that use struct arguments)
|
| |
|
