* Data Type used in kernel .
@ 2016-12-23 11:20 Wasim Akram
2016-12-23 11:33 ` Pasquier, Thomas
0 siblings, 1 reply; 6+ messages in thread
From: Wasim Akram @ 2016-12-23 11:20 UTC (permalink / raw)
To: kernelnewbies
Hi ,
I have seen "bool" data type is used in linux kernel code . Can we
get documentation on data type used in linux kernel development ?
--
Thanks and Regards
Wasim Akram
Ph: 7702843288
^ permalink raw reply [flat|nested] 6+ messages in thread
* Data Type used in kernel .
2016-12-23 11:20 Data Type used in kernel Wasim Akram
@ 2016-12-23 11:33 ` Pasquier, Thomas
2016-12-23 11:52 ` Nicholas Mc Guire
0 siblings, 1 reply; 6+ messages in thread
From: Pasquier, Thomas @ 2016-12-23 11:33 UTC (permalink / raw)
To: kernelnewbies
Hello Wasim,
On Fri, Dec 23, 2016 at 6:20 AM, Wasim Akram <wasim7702843288@gmail.com>
wrote:
> Hi ,
>
> I have seen "bool" data type is used in linux kernel code . Can we
> get documentation on data type used in linux kernel development ?
>
I think this should be a good start:
http://lxr.free-electrons.com/source/include/linux/types.h
>
> --
>
>
> Thanks and Regards
>
> Wasim Akram
> Ph: 7702843288
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20161223/761a0c97/attachment.html
^ permalink raw reply [flat|nested] 6+ messages in thread
* Data Type used in kernel .
2016-12-23 11:33 ` Pasquier, Thomas
@ 2016-12-23 11:52 ` Nicholas Mc Guire
2016-12-23 18:01 ` Greg KH
0 siblings, 1 reply; 6+ messages in thread
From: Nicholas Mc Guire @ 2016-12-23 11:52 UTC (permalink / raw)
To: kernelnewbies
On Fri, Dec 23, 2016 at 06:33:28AM -0500, Pasquier, Thomas wrote:
> Hello Wasim,
>
> On Fri, Dec 23, 2016 at 6:20 AM, Wasim Akram <wasim7702843288@gmail.com>
> wrote:
>
> > Hi ,
> >
> > I have seen "bool" data type is used in linux kernel code . Can we
> > get documentation on data type used in linux kernel development ?
> >
>
> I think this should be a good start:
> http://lxr.free-electrons.com/source/include/linux/types.h
>
one of the problems though is that there are a number of
"historic" type systems "left over" in the kernel it seems so
there actually is a bit of a mess and its not simple to
figure out what things really are. For x86_64 I have a list
of type matches I use for code reading (still not complete)
which might help.
x86 64bit:
==========
Type : equivalent types
bool : _Bool,
char : signed char, __signed__ char, __s8, s8, int8_t
unsigned char : unsigned char, u_char, __u8, u8, unchar, u_int8_t, uint8_t
__ticket_t,
insn_byte_t,
kprobe_opcode_t
short : signed short, __signed__ short, s16, int16_t
unsigned short : unsigned short, __u16, u16, u_short, ushort, u_int16_t, uint16_t,
__sum16,
umode_t,
__ticketpair_t,
apm_eventinfo_t,
apm_event_t,
Elf32_Sword,
Elf32_Half,
Elf64_Half,
Elf64_SHalf,
__kernel_sa_family_t,
__kernel_gid16_t, gid16_t,
__kernel_uid16_t, uid16_t,
__kernel_old_uid_t, old_uid_t,
__kernel_old_gid_t, old_gid_t,
arch cond: __le16/__be16
int : signed int, __signed__ int, __s32, s32, int32_t, s_int32_t
Elf64_Sword,
Elf64_Sxword,
key_serial_t,
insn_value_t,
__kernel_daddr_t, daddr_t,
__kernel_ipc_pid_t, pid_t,
__kernel_pid_t,
__kernel_mqd_t, mqd_t,
__kernel_key_t, key_t,
__kernel_timer_t timer_t,
unsigned int : unsigned, unsigned int, __u32, u32, u_int32_t, uInt, u_int, uint, uint32_t,
__wsum,
nlink_t,
gfp_t,
fmode_t,
oom_flags_t,
isolate_mode_t,
Elf32_Addr,
Elf32_Off,
Elf32_Word,
Elf64_Word,
key_perm_t,
insn_attr_t,
sk_buff_data_t,
sctp_assoc_t.
__kernel_dev_t, dev_t,
__kernel_uid32_t, uid_t, projid_t, qid_t
__kernel_gid32_t, gid_t,
__kernel_uid_t,
__kernel_gid_t,
__kernel_mode_t, mode_t,
arch cond: __le32/__be32
long : signed long, __kernel_long_t,
__kernel_suseconds_t, suseconds_t,
__kernel_ssize_t, ssize_t,
__kernel_ptrdiff_t,
__kernel_off_t, off_t,
__kernel_time_t, time_t,
__kernel_clock_t, clock_t,
unsigned long : __kernel_ulong_t, u_long, ulong
uintptr_t,
sector_t,
blkcnt_t,
irq_hw_number_t,
pteval_t,
pmdval_t,
pudval_t,
pgdval_t,
pgprotval_t,
vm_flags_t,
elf_greg_t,
cputime_t,
old_sigset_t,
aio_context_t,
flow_compare_t,
__kernel_ino_t, ino_t
__kernel_old_dev_t
__kernel_size_t. size_t,
arch cond: __le64/__be64
long long : signed long long, __signed__ long long, __s64, s64, int64_t
time64_t,
qsize_t,
__kernel_loff_t, loff_t,
unsigned long long: u64, __u64, uint64_t, u_int64_t
dma_addr_t,
cycles_t,
phys_addr_t, resource_size_t
cycle_t,
Elf64_Addr,
Elf64_Off,
Elf64_Xword,
cputime64_t,
netdev_features_t
^ permalink raw reply [flat|nested] 6+ messages in thread
* Data Type used in kernel .
2016-12-23 11:52 ` Nicholas Mc Guire
@ 2016-12-23 18:01 ` Greg KH
2016-12-24 8:06 ` Nicholas Mc Guire
0 siblings, 1 reply; 6+ messages in thread
From: Greg KH @ 2016-12-23 18:01 UTC (permalink / raw)
To: kernelnewbies
On Fri, Dec 23, 2016 at 11:52:33AM +0000, Nicholas Mc Guire wrote:
> On Fri, Dec 23, 2016 at 06:33:28AM -0500, Pasquier, Thomas wrote:
> > Hello Wasim,
> >
> > On Fri, Dec 23, 2016 at 6:20 AM, Wasim Akram <wasim7702843288@gmail.com>
> > wrote:
> >
> > > Hi ,
> > >
> > > I have seen "bool" data type is used in linux kernel code . Can we
> > > get documentation on data type used in linux kernel development ?
> > >
> >
> > I think this should be a good start:
> > http://lxr.free-electrons.com/source/include/linux/types.h
> >
> one of the problems though is that there are a number of
> "historic" type systems "left over" in the kernel it seems so
> there actually is a bit of a mess and its not simple to
> figure out what things really are. For x86_64 I have a list
> of type matches I use for code reading (still not complete)
> which might help.
>
> x86 64bit:
> ==========
>
> Type : equivalent types
> bool : _Bool,
> char : signed char, __signed__ char, __s8, s8, int8_t
> unsigned char : unsigned char, u_char, __u8, u8, unchar, u_int8_t, uint8_t
> __ticket_t,
> insn_byte_t,
> kprobe_opcode_t
> short : signed short, __signed__ short, s16, int16_t
> unsigned short : unsigned short, __u16, u16, u_short, ushort, u_int16_t, uint16_t,
> __sum16,
> umode_t,
> __ticketpair_t,
> apm_eventinfo_t,
> apm_event_t,
> Elf32_Sword,
> Elf32_Half,
> Elf64_Half,
> Elf64_SHalf,
> __kernel_sa_family_t,
> __kernel_gid16_t, gid16_t,
> __kernel_uid16_t, uid16_t,
> __kernel_old_uid_t, old_uid_t,
> __kernel_old_gid_t, old_gid_t,
> arch cond: __le16/__be16
> int : signed int, __signed__ int, __s32, s32, int32_t, s_int32_t
> Elf64_Sword,
> Elf64_Sxword,
> key_serial_t,
> insn_value_t,
> __kernel_daddr_t, daddr_t,
> __kernel_ipc_pid_t, pid_t,
> __kernel_pid_t,
> __kernel_mqd_t, mqd_t,
> __kernel_key_t, key_t,
> __kernel_timer_t timer_t,
> unsigned int : unsigned, unsigned int, __u32, u32, u_int32_t, uInt, u_int, uint, uint32_t,
> __wsum,
> nlink_t,
> gfp_t,
> fmode_t,
> oom_flags_t,
> isolate_mode_t,
> Elf32_Addr,
> Elf32_Off,
> Elf32_Word,
> Elf64_Word,
> key_perm_t,
> insn_attr_t,
> sk_buff_data_t,
> sctp_assoc_t.
> __kernel_dev_t, dev_t,
> __kernel_uid32_t, uid_t, projid_t, qid_t
> __kernel_gid32_t, gid_t,
> __kernel_uid_t,
> __kernel_gid_t,
> __kernel_mode_t, mode_t,
> arch cond: __le32/__be32
> long : signed long, __kernel_long_t,
> __kernel_suseconds_t, suseconds_t,
> __kernel_ssize_t, ssize_t,
> __kernel_ptrdiff_t,
> __kernel_off_t, off_t,
> __kernel_time_t, time_t,
> __kernel_clock_t, clock_t,
> unsigned long : __kernel_ulong_t, u_long, ulong
> uintptr_t,
> sector_t,
> blkcnt_t,
> irq_hw_number_t,
> pteval_t,
> pmdval_t,
> pudval_t,
> pgdval_t,
> pgprotval_t,
> vm_flags_t,
> elf_greg_t,
> cputime_t,
> old_sigset_t,
> aio_context_t,
> flow_compare_t,
> __kernel_ino_t, ino_t
> __kernel_old_dev_t
> __kernel_size_t. size_t,
> arch cond: __le64/__be64
> long long : signed long long, __signed__ long long, __s64, s64, int64_t
> time64_t,
> qsize_t,
> __kernel_loff_t, loff_t,
> unsigned long long: u64, __u64, uint64_t, u_int64_t
> dma_addr_t,
> cycles_t,
> phys_addr_t, resource_size_t
> cycle_t,
> Elf64_Addr,
> Elf64_Off,
> Elf64_Xword,
> cputime64_t,
> netdev_features_t
That's crazy. Just use the data types that the LDD book says to use for
in-kernel code:
u8, u16, u32, u64, s8, s16, s32, s64, int, bool
and if the data crosses the user/kernel boundry, use the correct ones
for that (__ in front, no int).
You can use others, but you better know what you are doing if you do :)
Hope this helps,
greg k-h
^ permalink raw reply [flat|nested] 6+ messages in thread
* Data Type used in kernel .
2016-12-23 18:01 ` Greg KH
@ 2016-12-24 8:06 ` Nicholas Mc Guire
2016-12-24 9:37 ` Greg KH
0 siblings, 1 reply; 6+ messages in thread
From: Nicholas Mc Guire @ 2016-12-24 8:06 UTC (permalink / raw)
To: kernelnewbies
On Fri, Dec 23, 2016 at 07:01:37PM +0100, Greg KH wrote:
> On Fri, Dec 23, 2016 at 11:52:33AM +0000, Nicholas Mc Guire wrote:
> > On Fri, Dec 23, 2016 at 06:33:28AM -0500, Pasquier, Thomas wrote:
> > > Hello Wasim,
> > >
> > > On Fri, Dec 23, 2016 at 6:20 AM, Wasim Akram <wasim7702843288@gmail.com>
> > > wrote:
> > >
> > > > Hi ,
> > > >
> > > > I have seen "bool" data type is used in linux kernel code . Can we
> > > > get documentation on data type used in linux kernel development ?
> > > >
> > >
> > > I think this should be a good start:
> > > http://lxr.free-electrons.com/source/include/linux/types.h
> > >
> > one of the problems though is that there are a number of
> > "historic" type systems "left over" in the kernel it seems so
> > there actually is a bit of a mess and its not simple to
> > figure out what things really are. For x86_64 I have a list
> > of type matches I use for code reading (still not complete)
> > which might help.
> >
> > x86 64bit:
> > ==========
> >
> > Type : equivalent types
> > bool : _Bool,
> > char : signed char, __signed__ char, __s8, s8, int8_t
> > unsigned char : unsigned char, u_char, __u8, u8, unchar, u_int8_t, uint8_t
> > __ticket_t,
> > insn_byte_t,
> > kprobe_opcode_t
> > short : signed short, __signed__ short, s16, int16_t
> > unsigned short : unsigned short, __u16, u16, u_short, ushort, u_int16_t, uint16_t,
> > __sum16,
> > umode_t,
> > __ticketpair_t,
> > apm_eventinfo_t,
> > apm_event_t,
> > Elf32_Sword,
> > Elf32_Half,
> > Elf64_Half,
> > Elf64_SHalf,
> > __kernel_sa_family_t,
> > __kernel_gid16_t, gid16_t,
> > __kernel_uid16_t, uid16_t,
> > __kernel_old_uid_t, old_uid_t,
> > __kernel_old_gid_t, old_gid_t,
> > arch cond: __le16/__be16
> > int : signed int, __signed__ int, __s32, s32, int32_t, s_int32_t
> > Elf64_Sword,
> > Elf64_Sxword,
> > key_serial_t,
> > insn_value_t,
> > __kernel_daddr_t, daddr_t,
> > __kernel_ipc_pid_t, pid_t,
> > __kernel_pid_t,
> > __kernel_mqd_t, mqd_t,
> > __kernel_key_t, key_t,
> > __kernel_timer_t timer_t,
> > unsigned int : unsigned, unsigned int, __u32, u32, u_int32_t, uInt, u_int, uint, uint32_t,
> > __wsum,
> > nlink_t,
> > gfp_t,
> > fmode_t,
> > oom_flags_t,
> > isolate_mode_t,
> > Elf32_Addr,
> > Elf32_Off,
> > Elf32_Word,
> > Elf64_Word,
> > key_perm_t,
> > insn_attr_t,
> > sk_buff_data_t,
> > sctp_assoc_t.
> > __kernel_dev_t, dev_t,
> > __kernel_uid32_t, uid_t, projid_t, qid_t
> > __kernel_gid32_t, gid_t,
> > __kernel_uid_t,
> > __kernel_gid_t,
> > __kernel_mode_t, mode_t,
> > arch cond: __le32/__be32
> > long : signed long, __kernel_long_t,
> > __kernel_suseconds_t, suseconds_t,
> > __kernel_ssize_t, ssize_t,
> > __kernel_ptrdiff_t,
> > __kernel_off_t, off_t,
> > __kernel_time_t, time_t,
> > __kernel_clock_t, clock_t,
> > unsigned long : __kernel_ulong_t, u_long, ulong
> > uintptr_t,
> > sector_t,
> > blkcnt_t,
> > irq_hw_number_t,
> > pteval_t,
> > pmdval_t,
> > pudval_t,
> > pgdval_t,
> > pgprotval_t,
> > vm_flags_t,
> > elf_greg_t,
> > cputime_t,
> > old_sigset_t,
> > aio_context_t,
> > flow_compare_t,
> > __kernel_ino_t, ino_t
> > __kernel_old_dev_t
> > __kernel_size_t. size_t,
> > arch cond: __le64/__be64
> > long long : signed long long, __signed__ long long, __s64, s64, int64_t
> > time64_t,
> > qsize_t,
> > __kernel_loff_t, loff_t,
> > unsigned long long: u64, __u64, uint64_t, u_int64_t
> > dma_addr_t,
> > cycles_t,
> > phys_addr_t, resource_size_t
> > cycle_t,
> > Elf64_Addr,
> > Elf64_Off,
> > Elf64_Xword,
> > cputime64_t,
> > netdev_features_t
>
> That's crazy. Just use the data types that the LDD book says to use for
Its crazy but the problem is that if you use basic data types to handle any
of those types that are in use it actually can end up being more confusing
that if you do not - for the basic types using the list you give below (rather
than any of those historic variatsion makes sense.
> in-kernel code:
> u8, u16, u32, u64, s8, s16, s32, s64, int, bool
It would be good to add a statement to CodingStyle stating something
like this. While the section 5) Typedefs does mention guidlines it does
not give a clear preference - would something like:
<snip>
With all this said on typedef usage (or rather prefered non-usage) the
prefered type system for any kernel only variables used is:
u8, u16, u32, u64, s8, s16, s32, s64, int, bool
and for anything shared between kernel and user-space:
__u8, __u16, __u32, __u64, __s8, __s16, __s32, __s64, bool
<snip>
be appropriate ?
> and if the data crosses the user/kernel boundry, use the correct ones
> for that (__ in front, no int).
>
> You can use others, but you better know what you are doing if you do :)
and section 5) of Documentation/process/coding-style.rst does give some
guidlines for creating new types.
thx!
hofrat
^ permalink raw reply [flat|nested] 6+ messages in thread
* Data Type used in kernel .
2016-12-24 8:06 ` Nicholas Mc Guire
@ 2016-12-24 9:37 ` Greg KH
0 siblings, 0 replies; 6+ messages in thread
From: Greg KH @ 2016-12-24 9:37 UTC (permalink / raw)
To: kernelnewbies
On Sat, Dec 24, 2016 at 08:06:25AM +0000, Nicholas Mc Guire wrote:
> On Fri, Dec 23, 2016 at 07:01:37PM +0100, Greg KH wrote:
> > On Fri, Dec 23, 2016 at 11:52:33AM +0000, Nicholas Mc Guire wrote:
> > > On Fri, Dec 23, 2016 at 06:33:28AM -0500, Pasquier, Thomas wrote:
> > > > Hello Wasim,
> > > >
> > > > On Fri, Dec 23, 2016 at 6:20 AM, Wasim Akram <wasim7702843288@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi ,
> > > > >
> > > > > I have seen "bool" data type is used in linux kernel code . Can we
> > > > > get documentation on data type used in linux kernel development ?
> > > > >
> > > >
> > > > I think this should be a good start:
> > > > http://lxr.free-electrons.com/source/include/linux/types.h
> > > >
> > > one of the problems though is that there are a number of
> > > "historic" type systems "left over" in the kernel it seems so
> > > there actually is a bit of a mess and its not simple to
> > > figure out what things really are. For x86_64 I have a list
> > > of type matches I use for code reading (still not complete)
> > > which might help.
> > >
> > > x86 64bit:
> > > ==========
> > >
> > > Type : equivalent types
> > > bool : _Bool,
> > > char : signed char, __signed__ char, __s8, s8, int8_t
> > > unsigned char : unsigned char, u_char, __u8, u8, unchar, u_int8_t, uint8_t
> > > __ticket_t,
> > > insn_byte_t,
> > > kprobe_opcode_t
> > > short : signed short, __signed__ short, s16, int16_t
> > > unsigned short : unsigned short, __u16, u16, u_short, ushort, u_int16_t, uint16_t,
> > > __sum16,
> > > umode_t,
> > > __ticketpair_t,
> > > apm_eventinfo_t,
> > > apm_event_t,
> > > Elf32_Sword,
> > > Elf32_Half,
> > > Elf64_Half,
> > > Elf64_SHalf,
> > > __kernel_sa_family_t,
> > > __kernel_gid16_t, gid16_t,
> > > __kernel_uid16_t, uid16_t,
> > > __kernel_old_uid_t, old_uid_t,
> > > __kernel_old_gid_t, old_gid_t,
> > > arch cond: __le16/__be16
> > > int : signed int, __signed__ int, __s32, s32, int32_t, s_int32_t
> > > Elf64_Sword,
> > > Elf64_Sxword,
> > > key_serial_t,
> > > insn_value_t,
> > > __kernel_daddr_t, daddr_t,
> > > __kernel_ipc_pid_t, pid_t,
> > > __kernel_pid_t,
> > > __kernel_mqd_t, mqd_t,
> > > __kernel_key_t, key_t,
> > > __kernel_timer_t timer_t,
> > > unsigned int : unsigned, unsigned int, __u32, u32, u_int32_t, uInt, u_int, uint, uint32_t,
> > > __wsum,
> > > nlink_t,
> > > gfp_t,
> > > fmode_t,
> > > oom_flags_t,
> > > isolate_mode_t,
> > > Elf32_Addr,
> > > Elf32_Off,
> > > Elf32_Word,
> > > Elf64_Word,
> > > key_perm_t,
> > > insn_attr_t,
> > > sk_buff_data_t,
> > > sctp_assoc_t.
> > > __kernel_dev_t, dev_t,
> > > __kernel_uid32_t, uid_t, projid_t, qid_t
> > > __kernel_gid32_t, gid_t,
> > > __kernel_uid_t,
> > > __kernel_gid_t,
> > > __kernel_mode_t, mode_t,
> > > arch cond: __le32/__be32
> > > long : signed long, __kernel_long_t,
> > > __kernel_suseconds_t, suseconds_t,
> > > __kernel_ssize_t, ssize_t,
> > > __kernel_ptrdiff_t,
> > > __kernel_off_t, off_t,
> > > __kernel_time_t, time_t,
> > > __kernel_clock_t, clock_t,
> > > unsigned long : __kernel_ulong_t, u_long, ulong
> > > uintptr_t,
> > > sector_t,
> > > blkcnt_t,
> > > irq_hw_number_t,
> > > pteval_t,
> > > pmdval_t,
> > > pudval_t,
> > > pgdval_t,
> > > pgprotval_t,
> > > vm_flags_t,
> > > elf_greg_t,
> > > cputime_t,
> > > old_sigset_t,
> > > aio_context_t,
> > > flow_compare_t,
> > > __kernel_ino_t, ino_t
> > > __kernel_old_dev_t
> > > __kernel_size_t. size_t,
> > > arch cond: __le64/__be64
> > > long long : signed long long, __signed__ long long, __s64, s64, int64_t
> > > time64_t,
> > > qsize_t,
> > > __kernel_loff_t, loff_t,
> > > unsigned long long: u64, __u64, uint64_t, u_int64_t
> > > dma_addr_t,
> > > cycles_t,
> > > phys_addr_t, resource_size_t
> > > cycle_t,
> > > Elf64_Addr,
> > > Elf64_Off,
> > > Elf64_Xword,
> > > cputime64_t,
> > > netdev_features_t
> >
> > That's crazy. Just use the data types that the LDD book says to use for
>
> Its crazy but the problem is that if you use basic data types to handle any
> of those types that are in use it actually can end up being more confusing
> that if you do not - for the basic types using the list you give below
> (rather than any of those historic variatsion makes sense.
I don't understand what you mean here. When would someone from
kernelnewbies ever have to deal with Elf64_Off?
> > in-kernel code:
> > u8, u16, u32, u64, s8, s16, s32, s64, int, bool
>
> It would be good to add a statement to CodingStyle stating something
> like this. While the section 5) Typedefs does mention guidlines it does
> not give a clear preference - would something like:
>
> <snip>
> With all this said on typedef usage (or rather prefered non-usage) the
> prefered type system for any kernel only variables used is:
>
> u8, u16, u32, u64, s8, s16, s32, s64, int, bool
>
> and for anything shared between kernel and user-space:
>
> __u8, __u16, __u32, __u64, __s8, __s16, __s32, __s64, bool
> <snip>
>
> be appropriate ?
Nope, just don't create new typedefs and you should be fine, coding
style already says that.
> > and if the data crosses the user/kernel boundry, use the correct ones
> > for that (__ in front, no int).
> >
> > You can use others, but you better know what you are doing if you do :)
>
> and section 5) of Documentation/process/coding-style.rst does give some
> guidlines for creating new types.
Yes, please do not create any new types, and you should be fine.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-12-24 9:37 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-12-23 11:20 Data Type used in kernel Wasim Akram
2016-12-23 11:33 ` Pasquier, Thomas
2016-12-23 11:52 ` Nicholas Mc Guire
2016-12-23 18:01 ` Greg KH
2016-12-24 8:06 ` Nicholas Mc Guire
2016-12-24 9:37 ` Greg KH
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).