LINUX.ORG.RU
Форум — Development  

[C-Linux] Где лежат самые кошерные заголовочные файлы


0

1

Решил навести порядок в голове. Вот к примеру пользуюсь я функцией ioctl, мне нужна она сама, плюс дефайны соответствующих операций. 

root@aldm-desktop:/usr/include# find /usr/include -type f -exec grep "BLKGETSIZE" {} \; -print
#define BLKGETSIZE _IO(0x12, 96) /* Return device size.  */
#define BLKGETSIZE64 _IOR(0x12,114,size_t) /* return device size.  */
/usr/include/i386-linux-gnu/sys/mount.h
#define BLKGETSIZE _IO(0x12,96)	/* return device size /512 (long *arg) */
#define BLKGETSIZE64 _IOR(0x12,114,size_t)	/* return device size in bytes (u64 *arg) */
/usr/include/linux/fs.h
#define VKI_BLKGETSIZE _VKI_IO(0x12,96) /* return device size /512 (long *arg) */
#define VKI_BLKGETSIZE64 _VKI_IOR(0x12,114,vki_size_t) /* return device size in bytes (u64 *arg) */
/usr/include/valgrind/vki/vki-linux.h
Видим что интересующая нас константа лежит в двух каталогах /usr/include/i386-linux-gnu/ и /usr/include/linux/ , да ещё и в разных файлах. Кроме того, в этих каталогах есть и одинаковые файлы, к примеру time.h есть и там и там.

Теперь вопросы:
1. Какой каталог полнее?
2. Какой каталог использовать правильнее?
3. Нафига два каталога?

← [android] Heap Space
Как отобразить вывод perf report на место в .so файле при отсутствии таблицы имён? →

правильно использовать то что в мане написано.

А вот какого хрена всё именно так устроено (там куча других чудес) у меня тоже вызывает вопросы. Для меня всё это очень непрозрачно.

true_admin ★★★★★
()

Если ты не строишь свой собственный дистрибутив, свой тулчейн, и не делаешь что-то странное, то надо использовать стандартные пути компилятора.

То есть то, что в /usr/include, то, что выдает pkg-config пакет --cflags, и тп. Руками в эту кухню чучше не лезть. Используй стандарты, man'ы и прочее. Если интересно, что использует компилятор, добавь -v в командную строку.

А вообще, то, что лежит в исходниках ядра и в так называемых «linux-headers» и тп - оно не предназначено для использования напрямую юзерспейсом, glibc при сборке там обработку делает, скрипты гоняет и генерит своих хедеров. То есть нужно использовать продукт обработки glibc и потом gcc, обычно сидящий в /usr/include.

slapin ★★★★★
()

в данном случае — «/usr/include/linux/fs.h» (<linux/fs.h>), т.к. это «первоисточник» константы BLKGETSIZE.

arsi ★★★★★
()
Ответ на: комментарий от dmitryalexeeff

Я предлагаю открыть мануал и подключить sys/ioctl.h

tensai_cirno ★★★★★
()
Ответ на: комментарий от tensai_cirno

Тут нету кошерных заголовочных файлов. Это линукс. 

#include <windows.h>
#include <winioctl.h>

typedef struct _GETVERSIONOUTPARAMS
{
  BYTE bVersion;
  BYTE bRevision;
  BYTE bReserved;
  BYTE bIDEDeviceMap;
  DWORD fCapabilities;
 DWORD dwReserved[4];
} GETVERSIONOUTPARAMS, *PGETVERSIONOUTPARAMS, *LPGETVERSIONOUTPARAMS;

/* бла-бла-бла */
DeviceIoControl(hPhysicalDriveIOCTL, DFP_RECEIVE_DRIVE_DATA, (LPVOID)pSCIP, sizeof(SENDCMDINPARAMS) - 1, (LPVOID)pSCOP, sizeof(SENDCMDOUTPARAMS) + IDENTIFY_BUFFER_SIZE - 1, lpcbBytesReturned, NULL);

Это по твоему кошерно? Линукс по сравнении с этим безумием - идеален

Esh ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← [android] Heap Space
Development
Как отобразить вывод perf report на место в .so файле при отсутствии таблицы имён? →