Searched hist:248 (Results 1 - 25 of 37) sorted by relevance

12

/src/sys/netinet/
H A Dportalgo.h1.3 Fri Oct 28 05:18:39 GMT 2022 ozaki-r inpcb: integrate data structures of PCB into one

Data structures of network protocol control blocks (PCBs), i.e.,
struct inpcb, in6pcb and inpcb_hdr, are not organized well. Users of
the data structures have to handle them separately and thus the code
is cluttered and duplicated.

The commit integrates the data structures into one, struct inpcb. As a
result, users of PCBs only have to handle just one data structure, so
the code becomes simple.

One drawback is that the data size of PCB for IPv4 increases by 40 bytes
(from 248 bytes to 288 bytes).

H A Dtcp_syncache.c1.3 Fri Oct 28 05:18:39 GMT 2022 ozaki-r inpcb: integrate data structures of PCB into one

Data structures of network protocol control blocks (PCBs), i.e.,
struct inpcb, in6pcb and inpcb_hdr, are not organized well. Users of
the data structures have to handle them separately and thus the code
is cluttered and duplicated.

The commit integrates the data structures into one, struct inpcb. As a
result, users of PCBs only have to handle just one data structure, so
the code becomes simple.

One drawback is that the data size of PCB for IPv4 increases by 40 bytes
(from 248 bytes to 288 bytes).

H A Dportalgo.c1.12 Fri Oct 28 05:18:39 GMT 2022 ozaki-r inpcb: integrate data structures of PCB into one

Data structures of network protocol control blocks (PCBs), i.e.,
struct inpcb, in6pcb and inpcb_hdr, are not organized well. Users of
the data structures have to handle them separately and thus the code
is cluttered and duplicated.

The commit integrates the data structures into one, struct inpcb. As a
result, users of PCBs only have to handle just one data structure, so
the code becomes simple.

One drawback is that the data size of PCB for IPv4 increases by 40 bytes
(from 248 bytes to 288 bytes).

H A Dtcp_vtw.c1.22 Fri Oct 28 05:18:39 GMT 2022 ozaki-r inpcb: integrate data structures of PCB into one

Data structures of network protocol control blocks (PCBs), i.e.,
struct inpcb, in6pcb and inpcb_hdr, are not organized well. Users of
the data structures have to handle them separately and thus the code
is cluttered and duplicated.

The commit integrates the data structures into one, struct inpcb. As a
result, users of PCBs only have to handle just one data structure, so
the code becomes simple.

One drawback is that the data size of PCB for IPv4 increases by 40 bytes
(from 248 bytes to 288 bytes).
H A Din_pcb.h1.71 Fri Oct 28 05:18:39 GMT 2022 ozaki-r inpcb: integrate data structures of PCB into one

Data structures of network protocol control blocks (PCBs), i.e.,
struct inpcb, in6pcb and inpcb_hdr, are not organized well. Users of
the data structures have to handle them separately and thus the code
is cluttered and duplicated.

The commit integrates the data structures into one, struct inpcb. As a
result, users of PCBs only have to handle just one data structure, so
the code becomes simple.

One drawback is that the data size of PCB for IPv4 increases by 40 bytes
(from 248 bytes to 288 bytes).
H A Dtcp_timer.c1.97 Fri Oct 28 05:18:39 GMT 2022 ozaki-r inpcb: integrate data structures of PCB into one

Data structures of network protocol control blocks (PCBs), i.e.,
struct inpcb, in6pcb and inpcb_hdr, are not organized well. Users of
the data structures have to handle them separately and thus the code
is cluttered and duplicated.

The commit integrates the data structures into one, struct inpcb. As a
result, users of PCBs only have to handle just one data structure, so
the code becomes simple.

One drawback is that the data size of PCB for IPv4 increases by 40 bytes
(from 248 bytes to 288 bytes).
H A Din_pcb.c1.192 Fri Oct 28 05:18:39 GMT 2022 ozaki-r inpcb: integrate data structures of PCB into one

Data structures of network protocol control blocks (PCBs), i.e.,
struct inpcb, in6pcb and inpcb_hdr, are not organized well. Users of
the data structures have to handle them separately and thus the code
is cluttered and duplicated.

The commit integrates the data structures into one, struct inpcb. As a
result, users of PCBs only have to handle just one data structure, so
the code becomes simple.

One drawback is that the data size of PCB for IPv4 increases by 40 bytes
(from 248 bytes to 288 bytes).
H A Draw_ip.c1.182 Fri Oct 28 05:18:39 GMT 2022 ozaki-r inpcb: integrate data structures of PCB into one

Data structures of network protocol control blocks (PCBs), i.e.,
struct inpcb, in6pcb and inpcb_hdr, are not organized well. Users of
the data structures have to handle them separately and thus the code
is cluttered and duplicated.

The commit integrates the data structures into one, struct inpcb. As a
result, users of PCBs only have to handle just one data structure, so
the code becomes simple.

One drawback is that the data size of PCB for IPv4 increases by 40 bytes
(from 248 bytes to 288 bytes).
H A Dtcp_output.c1.215 Fri Oct 28 05:18:39 GMT 2022 ozaki-r inpcb: integrate data structures of PCB into one

Data structures of network protocol control blocks (PCBs), i.e.,
struct inpcb, in6pcb and inpcb_hdr, are not organized well. Users of
the data structures have to handle them separately and thus the code
is cluttered and duplicated.

The commit integrates the data structures into one, struct inpcb. As a
result, users of PCBs only have to handle just one data structure, so
the code becomes simple.

One drawback is that the data size of PCB for IPv4 increases by 40 bytes
(from 248 bytes to 288 bytes).
/src/sys/arch/m68k/060sp/
H A Dnetbsd060sp.S1.7 Thu Jul 12 17:17:45 GMT 2001 scw branches: 1.7.6; 1.7.248;
Use PCB_ONFAULT instead of hardcoding a value of 64. This is fine
for Amiga and Atari but not for other m68k ports which use m68k/pcb.h.

/src/sbin/atactl/
H A Datactl.c1.76 Tue May 10 08:08:59 GMT 2016 mrg branches: 1.76.2;
update the micron smart codes for 247/248 to match data i found in
micron's "TN-FD-33: M510DC SSD SMART Implementation Introduction"
document.

these two values can be used to calculate the write amplication
factor:

WAF = ( A247 + A248 ) / A247
1.75 Mon Sep 21 06:05:00 GMT 2015 mrg add smart IDs 210, 246, 247 and 248 (Micron):
+ { 210, "Successful RAIN Recovery Count", NULL },
+ { 246, "Total Host Sector Writes", NULL },
+ { 247, "Contact Factory (Micron)", NULL },
+ { 248, "Contact Factory (Micron)", NULL },

(eek i hope 247 and 248 don't move.)
1.75 Mon Sep 21 06:05:00 GMT 2015 mrg add smart IDs 210, 246, 247 and 248 (Micron):
+ { 210, "Successful RAIN Recovery Count", NULL },
+ { 246, "Total Host Sector Writes", NULL },
+ { 247, "Contact Factory (Micron)", NULL },
+ { 248, "Contact Factory (Micron)", NULL },

(eek i hope 247 and 248 don't move.)
1.75 Mon Sep 21 06:05:00 GMT 2015 mrg add smart IDs 210, 246, 247 and 248 (Micron):
+ { 210, "Successful RAIN Recovery Count", NULL },
+ { 246, "Total Host Sector Writes", NULL },
+ { 247, "Contact Factory (Micron)", NULL },
+ { 248, "Contact Factory (Micron)", NULL },

(eek i hope 247 and 248 don't move.)
/src/sys/netinet6/
H A Dudp6_var.h1.31 Fri Oct 28 05:18:39 GMT 2022 ozaki-r inpcb: integrate data structures of PCB into one

Data structures of network protocol control blocks (PCBs), i.e.,
struct inpcb, in6pcb and inpcb_hdr, are not organized well. Users of
the data structures have to handle them separately and thus the code
is cluttered and duplicated.

The commit integrates the data structures into one, struct inpcb. As a
result, users of PCBs only have to handle just one data structure, so
the code becomes simple.

One drawback is that the data size of PCB for IPv4 increases by 40 bytes
(from 248 bytes to 288 bytes).

H A Din6_pcb.h1.54 Fri Oct 28 05:18:39 GMT 2022 ozaki-r inpcb: integrate data structures of PCB into one

Data structures of network protocol control blocks (PCBs), i.e.,
struct inpcb, in6pcb and inpcb_hdr, are not organized well. Users of
the data structures have to handle them separately and thus the code
is cluttered and duplicated.

The commit integrates the data structures into one, struct inpcb. As a
result, users of PCBs only have to handle just one data structure, so
the code becomes simple.

One drawback is that the data size of PCB for IPv4 increases by 40 bytes
(from 248 bytes to 288 bytes).
H A Din6_src.c1.89 Fri Oct 28 05:18:39 GMT 2022 ozaki-r inpcb: integrate data structures of PCB into one

Data structures of network protocol control blocks (PCBs), i.e.,
struct inpcb, in6pcb and inpcb_hdr, are not organized well. Users of
the data structures have to handle them separately and thus the code
is cluttered and duplicated.

The commit integrates the data structures into one, struct inpcb. As a
result, users of PCBs only have to handle just one data structure, so
the code becomes simple.

One drawback is that the data size of PCB for IPv4 increases by 40 bytes
(from 248 bytes to 288 bytes).
H A Dip6_var.h1.93 Fri Oct 28 05:18:39 GMT 2022 ozaki-r inpcb: integrate data structures of PCB into one

Data structures of network protocol control blocks (PCBs), i.e.,
struct inpcb, in6pcb and inpcb_hdr, are not organized well. Users of
the data structures have to handle them separately and thus the code
is cluttered and duplicated.

The commit integrates the data structures into one, struct inpcb. As a
result, users of PCBs only have to handle just one data structure, so
the code becomes simple.

One drawback is that the data size of PCB for IPv4 increases by 40 bytes
(from 248 bytes to 288 bytes).

H A Din6_pcb.c1.172 Fri Oct 28 05:18:39 GMT 2022 ozaki-r inpcb: integrate data structures of PCB into one

Data structures of network protocol control blocks (PCBs), i.e.,
struct inpcb, in6pcb and inpcb_hdr, are not organized well. Users of
the data structures have to handle them separately and thus the code
is cluttered and duplicated.

The commit integrates the data structures into one, struct inpcb. As a
result, users of PCBs only have to handle just one data structure, so
the code becomes simple.

One drawback is that the data size of PCB for IPv4 increases by 40 bytes
(from 248 bytes to 288 bytes).
H A Dudp6_usrreq.c1.151 Fri Oct 28 05:18:39 GMT 2022 ozaki-r inpcb: integrate data structures of PCB into one

Data structures of network protocol control blocks (PCBs), i.e.,
struct inpcb, in6pcb and inpcb_hdr, are not organized well. Users of
the data structures have to handle them separately and thus the code
is cluttered and duplicated.

The commit integrates the data structures into one, struct inpcb. As a
result, users of PCBs only have to handle just one data structure, so
the code becomes simple.

One drawback is that the data size of PCB for IPv4 increases by 40 bytes
(from 248 bytes to 288 bytes).
/src/sys/netipsec/
H A Dipsec6.h1.31 Fri Oct 28 05:18:39 GMT 2022 ozaki-r inpcb: integrate data structures of PCB into one

Data structures of network protocol control blocks (PCBs), i.e.,
struct inpcb, in6pcb and inpcb_hdr, are not organized well. Users of
the data structures have to handle them separately and thus the code
is cluttered and duplicated.

The commit integrates the data structures into one, struct inpcb. As a
result, users of PCBs only have to handle just one data structure, so
the code becomes simple.

One drawback is that the data size of PCB for IPv4 increases by 40 bytes
(from 248 bytes to 288 bytes).

H A Dipsec.h1.92 Fri Oct 28 05:18:39 GMT 2022 ozaki-r inpcb: integrate data structures of PCB into one

Data structures of network protocol control blocks (PCBs), i.e.,
struct inpcb, in6pcb and inpcb_hdr, are not organized well. Users of
the data structures have to handle them separately and thus the code
is cluttered and duplicated.

The commit integrates the data structures into one, struct inpcb. As a
result, users of PCBs only have to handle just one data structure, so
the code becomes simple.

One drawback is that the data size of PCB for IPv4 increases by 40 bytes
(from 248 bytes to 288 bytes).
H A Dipsec.c1.174 Fri Oct 28 05:18:39 GMT 2022 ozaki-r inpcb: integrate data structures of PCB into one

Data structures of network protocol control blocks (PCBs), i.e.,
struct inpcb, in6pcb and inpcb_hdr, are not organized well. Users of
the data structures have to handle them separately and thus the code
is cluttered and duplicated.

The commit integrates the data structures into one, struct inpcb. As a
result, users of PCBs only have to handle just one data structure, so
the code becomes simple.

One drawback is that the data size of PCB for IPv4 increases by 40 bytes
(from 248 bytes to 288 bytes).
/src/lib/libc/stdio/
H A Dprintf.31.4 Mon May 16 20:15:04 GMT 1994 jtc Fix typo, from Giles Lean (Fixes bug #248)
/src/sys/arch/sparc64/include/
H A Dparam.h1.54 Thu Jul 10 06:24:02 GMT 2014 jdc Increase maximum MSGBUFSIZE to 248k.
While here, remove 2 sparc(32)-only entries (from mrg@).
/src/lib/libc/gen/
H A Darc4random.c1.28 Wed Jan 21 02:47:39 GMT 2015 riastradh Use ChaCha20 here as advertised, not ChaCha8.

Oops.

Fortunately, there is no public cryptanalysis even of ChaCha8: the
best published attack is on ChaCha7 with time complexity 2^248.

/src/sys/arch/sun3/dev/
H A Dfd.c1.78 Wed Aug 20 17:48:57 GMT 2014 tsutsui branches: 1.78.2;
Sync with sparc/dev/fd.c rev 1.155.

> Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().

Note sun3 still uses gcc 4.5.4 but also panicked by this old bug,
so probably this problem was triggered by not gcc 4.8 but struct disk
changes (struct disk_geom was added in <sys/disk.h> rev 1.58),
which increased sizeof(struct fd_softc) from 248 bytes to 296 bytes.
(i.e. now struct fd_softc could be allocated in a different pool block,
probably near the wrong pointer of the struct disklabel)

Anyway, this fix should be pullued up to netbsd-7.
(probably I'm the only user of floppy on sun3 though)
/src/sys/kern/
H A Dkern_time.c1.197 Sun Mar 10 14:45:53 GMT 2019 kre branches: 1.197.4;
Fix the code that deals with very long sleeps (> 248 days) which
go beyond the maximum that the callout mechanism can handle.
[See the comments in tvtohz() in subr_sleep.c for the details.]

When that happens the timeout is clamped to MAX_INT (ticks), and the
code in nanosleep1() looped (or tried to) repeating the sleep (aka
kpause()) until the requested end time for the sleep was reached.

Unfortunately, the code assumed that kpause() would return 0 when
it returned after the timeout expired. But it doesn't, it returns
EWOULDBLOCK instead (why is incomprehensible to me, but I assume
there is a reason.) [That comes from sleepq_block() which returns
EWOULDBLOCK when callout_halt() indicates that the callout had fired,
which is exactly what has happened when the time has elapsed.]

There was already code to deal with that EWOULDBLOCK and return 0
instead of an error in that case - but it was placed after the
error code was tested against 0 for the purposes of the loop.

Simply move the EWOULDBLOCK->0 mapping earlier, so the code which
is expecting "error == 0" to mean "nothing went wrong" actually
gets to see that happen, and the loop can actually loop.

(Someday the loop should probably be rewritten as a loop, instead of
as a bunch of code followed by a "goto again"!)

Completed in 183 milliseconds

12