¿Es absolutamente necesaria la programación de sistemas abiertos en Unix?
2. Asigne una nueva estructura de archivo de estructura
3. Busque o cree una dentry correspondiente según el nombre de ruta ingresado
>4. Cree un enlace desde fd a esta estructura de archivos de estructura
El directorio copiado en WORD no parece funcionar directamente. Es mejor ponerlo en el hilo principal para ver...
La función de entrada de la función Abrir del espacio de usuario en el kernel es sys_open
A través de grep open /usr/include /asm/unistd_64 .h encontrado
#define __NR_open 2
__SYSCALL(__ NR_open, sys_open)
Mirando unistd_64.h, podemos suponer que el La función de apertura del espacio de usuario eventualmente se llamará llamada al sistema sys_open con la llamada al sistema número 2 para iniciar la llamada al sistema sys_open (después de todo, como es la práctica general con glibc, los nombres de las funciones del espacio de usuario son muy similares a los llamados por el espacio del kernel, entonces, si necesita obtener una estimación muy precisa, mire (después de todo, la práctica general de glibc es tener los nombres de las funciones del espacio de usuario muy similares a los nombres de las funciones del espacio del kernel, por lo que si necesita una estimación muy precisa, Puede mirar el código fuente de glibc y encontrar el número sys_open correspondiente. Luego compárelo con el número sys_open del kernel. No entraremos en detalles aquí
El contenido de la función Sys_open
SYSCALL_DEFINE3(open, const char ___ user *. , nombre de archivo, int).user *, nombre de archivo, int, banderas, umode_t, modo)
{
long ret;
if (force_o_largefile())
flags |= O_LARGEFILE;
ret = do _sys_open(AT_FDCWD, filename, flags, mode);
/* Evite las interrupciones REGPARM en x86: */
asmlinkage_protect(3, ret, filename , flags, mode);
return ret;
}
Entre ellos, primera llamada. force_o_largefile() para determinar si es necesario configurar el identificador de archivo grande y luego llame a do_sys_open para completar el trabajo específico.
Entre ellos
force_o_largefile()
En sistemas IA64, arch/ia64/include/asm/fcntl.h se define de la siguiente manera
#define _ASM_IA64_FCNTL_H
#define force_o_largefile() (personalidad(actual->personalidad) != PER_LINUX32)
#include
#endif / * _ASM_IA64_FCNTL_H */
Y el resto está en include/linux/fcntl.h
#ifndef force_o_largefile
#define force_o_largefile() (BITS_PER_LONG != 32 )
#endif
Entonces, force_o_largefile() es verdadero en todos los sistemas operativos que no son de 32 bits y falso en sistemas operativos de 32 bits
Además, Puede comprobar el bitness del sistema operativo:
# grep CONFIG_64BIT /boot /config-2.6.32-220.el6.x86_64
CONFIG_64BIT=y //64 bits
#ifdef CONFIG_64BIT
#define BITS_PER_LONG 64
#else
#define BITS_PER_LONG 32
#endif /* CONFIG_64BIT */ /
Entonces: esto solo es incorrecto en sistemas operativos de 32 bits (aquí no se considera la arquitectura IA64, estamos considerando la arquitectura x86), por lo que en sistemas de 64 bits la bandera se agregará automáticamente a O_LARGEFILE medio. LARGEFILE, 32 bits no lo tiene, por lo que el tamaño máximo del archivo se ve afectado por el i_size de 32 bits en el nodo de índice, que representa el tamaño del archivo y solo puede acceder a los segundos 32 bytes, que son 4 GB (de hecho , los bits altos generalmente no se usan, por lo que generalmente solo 2G). Después de agregar O_LAGEFILE y habilitarlo, el campo i_dir_acl del nodo de índice también puede representar el tamaño del archivo. De esta manera, el número de bits se convierte en 64 bits y 2 bits de 64 bits se convierten en 4 GB * 4 GB. ya muy grande.