From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pat LaVarre Subject: Re: udf.ko writes grokked most quickly how Date: 20 Nov 2003 10:13:53 -0700 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <1069348432.7511.2.camel@patrh9> References: <1069347191.7211.7.camel@patrh9> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: Received: from email-out1.iomega.com ([147.178.1.82]:60584 "EHLO email.iomega.com") by vger.kernel.org with ESMTP id S262360AbTKTROT (ORCPT ); Thu, 20 Nov 2003 12:14:19 -0500 Received: from royntex01.iomegacorp.com (unknown [147.178.90.120]) by email.iomega.com (Postfix) with ESMTP id 718A725E1 for ; Thu, 20 Nov 2003 10:14:18 -0700 (MST) To: linux-fsdevel@vger.kernel.org In-Reply-To: <1069347191.7211.7.camel@patrh9> List-Id: linux-fsdevel.vger.kernel.org cd linux-2.6.0-test9/fs/udf vi *.h // ecma_167.h linux/types.h may be giving us uint8_t, uint16_t etc. VSD_STD_ID_BEA01 is the "BEA01" string of mkudffs hexdump. // osta_udf.h UDF_ID_DEVELOPER "*Linux UDFFS" maybe distinguishes our volumes from others. UDF_ID_MAC_RESOURCE "*UDF Mac ResourceFork" etc. acknowledges Mac exists. UDF_ID_NON_ALLOC includes the "Non-Allocatable Space" string of some Windows views of udf discs. Many of UDF_OS_ID_* are 0x00U but have the same suffix as distinct UDF_OS_CLASS. // udfdecl.h UDF_NAME_LEN of 255, UDF_PATH_LEN of 1023, enough forever, right. # (UDF_I_USE(inode) ... Ouch a form of C I'm too ignorant to immediately understand. #define UDF_PATH_LEN 1023 redundant ok why I wonder. Here be our extern's. // udfend.h Prefix le maybe means little-endian. Why endian.h is not enough I do not yet know. // udf_i.h // udf_sb.h UDF_SUPER_MAGIC 0x15013346 ... hmmm ... bash of $'\x55\x41\x33\x46' is "UA3F".