Граф коммитов

14 Коммитов

Автор SHA1 Сообщение Дата
Jeff Layton 3410602732 [CIFS] remove cifs_strfromUCS_le
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
2009-05-02 04:59:34 +00:00
Steve French d185cda771 [CIFS] rename cifs_strndup to cifs_strndup_from_ucs
In most cases, cifs_strndup is converting from Unicode (UCS2 / UTF-32) to
the configured local code page for the Linux mount (usually UTF8), so
Jeff suggested that to make it more clear that cifs_strndup is doing
a conversion not just memory allocation and copy, rename the function
to including "from_ucs" (ie Unicode)

Signed-off-by: Steve French <sfrench@us.ibm.com>
2009-04-30 17:45:10 +00:00
Jeff Layton 066ce68994 cifs: rename cifs_strlcpy_to_host and make it use new functions
Rename cifs_strlcpy_to_host to cifs_strndup since that better describes
what this function really does. Then, convert it to use the new string
conversion and measurement functions that work in units of bytes rather
than wide chars.

Signed-off-by: Jeff Layton <jlayton@redhat.com>
Acked-by: Suresh Jayaraman <sjayaraman@suse.de>
Signed-off-by: Steve French <sfrench@us.ibm.com>
2009-04-30 15:45:00 +00:00
Jeff Layton 69f801fcaa cifs: add new function to get unicode string length in bytes
Working in units of words means we do a lot of unnecessary conversion back
and forth. Standardize on bytes instead since that's more useful for
allocating buffers and such. Also, remove hostlen_fromUCS since the new
function has a similar purpose.

Signed-off-by: Jeff Layton <jlayton@redhat.com>
Acked-by: Suresh Jayaraman <sjayaraman@suse.de>
Signed-off-by: Steve French <sfrench@us.ibm.com>
2009-04-30 15:45:00 +00:00
Jeff Layton 7fabf0c947 cifs: add replacement for cifs_strtoUCS_le called cifs_from_ucs2
Add a replacement function for cifs_strtoUCS_le. cifs_from_ucs2
takes args for the source and destination length so that we can ensure
that the function is confined within the intended buffers.

Signed-off-by: Jeff Layton <jlayton@redhat.com>
Acked-by: Suresh Jayaraman <sjayaraman@suse.de>
Signed-off-by: Steve French <sfrench@us.ibm.com>
2009-04-30 15:44:59 +00:00
Steve French ad7a2926b9 [CIFS] reduce checkpatch warnings
Signed-off-by: Steve French <sfrench@us.ibm.com>
2008-02-07 23:25:02 +00:00
Steve French 50c2f75388 [CIFS] whitespace/formatting fixes
This should be the last big batch of whitespace/formatting fixes.
checkpatch warnings for the cifs directory are down about 90% and
many of the remaining ones are harder to remove or make the code
harder to read.

Signed-off-by: Steve French <sfrench@us.ibm.com>
2007-07-13 00:33:32 +00:00
Steve French 221601c3d1 [CIFS] whitespace cleanup part 2
Various coding style problems found by running the new
   checkpatch.pl script against fs/cifs.  3 more files
   fixed up.

Signed-off-by: Steve French <sfrench@us.ibm.com>
2007-06-05 20:35:06 +00:00
Steve French 3a9f462f6d [CIFS] Remove unnecessary parm to cifs_reopen_file
Also expand debug entry to show which character on a failed Unicode
mapping.

Acked-by: Shaggy <shaggy@us.ibm.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
2007-04-04 17:10:24 +00:00
Steve French 3979877e56 [CIFS] Support for setting up SMB sessions to legacy lanman servers 2006-05-31 22:40:51 +00:00
Steve French e89dc92096 [CIFS] Cleanup sparse warnings for unicode little endian casts
Following Shaggy's suggestion, do a better job on the unicode string
handling routines in cifs in specifying that the wchar_t are really
little endian widechars (__le16).

Signed-off-by: Steve French <sfrench@us.ibm.com>
2005-11-11 15:18:19 -08:00
Steve French 69114089b7 [CIFS] Reduce sparse endian warnings
Signed-off-by: Steve French <sfrench@us.ibm.com>
2005-11-10 19:28:44 -08:00
Steve French 6c91d362f1 [PATCH] cifs: finish up of special character mapping capable unicode conversion routine part 2 of 3
Signed-off-by: Steve French (sfrench@us.ibm.com)
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-28 22:41:06 -07:00
Linus Torvalds 1da177e4c3 Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
2005-04-16 15:20:36 -07:00